SGI Freeware 1998 November/Freeware November 1998.img/dist/fw_UDELxntp.idb/usr/freeware/docs/xntpd/faq.z/faq

Text File | 1998-01-21 | 137KB | 3,253 lines

Received: from louie.udel.edu by huey.udel.edu id aa25630; 1 May 94 10:13 EDT
Received: from ni.umd.edu by louie.udel.edu id aa05526; 1 May 94 10:07 EDT
Received: by ni.umd.edu id AA23445
  (5.65c/IDA-1.4.4 for ntp-list); Sun, 1 May 1994 10:05:23 -0400
Received: from frogpond.rutgers.edu by ni.umd.edu with SMTP id AA23441
  (5.65c/IDA-1.4.4 for <[e-mail]>); Sun, 1 May 1994 10:05:17 -0400
Received: by frogpond.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
    id AA04620; Sun, 1 May 94 10:05:05 EDT
Date: Sun, 1 May 94 10:05:05 EDT
From: Rick Thomas <[e-mail]>
Message-Id: <[e-mail]>
Subject: Preliminary FAQ -- send updates to [e-mail]
Expires: Wed,  1 Jun 1994 00:00:01 EDT
Apparently-To: [e-mail]


Everybody talks about how we need a FAQ, but nobody does anything about it.
So I decided to do something about it.  Here is the text of several recent
messages that answered questions that everyone agrees should be on a FAQ.

Send updates to me --
Please write it up in a form I can include in the FAQ, and I'll include it.

Note, This is a "non-fat" FAQ.  I include stuff from other people that
I think is applicable.  I include it as it comes to me, warts and all.
I don't usually write things myself because I don't have the time.  I
don't usually edit things unless I write them myself.

Because of the un-edited format, you should read the *whole thing*
before you act on anything you read here.  Frequently, later items
contain corrections to earlier items.  I have tried to group related
items together, but sometimes that is not possible.

This was last updated $Date: 1994/05/01 05:30:41 $

I post the accumulation once a month.

It's rough but ready.

========================================================================
Rick Thomas, Manager Supercomputer Remote Access Center
Rutgers University, College of Engineering
Internet: [e-mail]
UUCP: {any backbone site}!rutgers!rbthomas
========================================================================

Standard disclaimers apply.  All messages quoted here are the opinions
of their respective authors, and do not necessarily represent the opinions
(if any) of their respective employers, or of the compiler of this FAQ.
If you act on the advice contained herein you do so at your own risk.
Nobody involved makes any warranty.

=============================================================================
From: [e-mail] (Mike Iglesias)
Subject: Re: xntpd: previous time adjustment didn't complete

[e-mail] (Rob Callahan) writes:
>I am also getting lots (I mean lots) of these messages on all Suns running
>xntpd as a client. An example of the /usr/adm/messages file follows:
>
>Feb 24 10:03:21 lilith last message repeated 48 times
>Feb 24 10:03:30 lilith xntpd[535]: Previous time adjustment didn't complete

Make sure you run tickadj on your Suns before you run xntpd.  Here's
how we run tickadj:

   tickadj -A -s -q -t 9999

You can leave off the -t 9999 if you want.  We find that our Suns drift
less with that setting.

Also, if you don't use a window system on the console, the slow console
proms will make the system loose interrupts and the time will drift.

We *really* need a FAQ for this list.  This question gets asked several times
a month.  :-(

=============================================================================
From: [e-mail] (Glenn F. Leavell)
Subject: Re: xntpd: previous time adjustment didn't complete

I recently worte:

>We're using xntp3 to broadcast the time on our campus network.  Client
>machines accross the network "listen" for the time by running xntpd as:
>
>               xntpd -b -f /etc/ntp.drift
>
>Recently, some of our Sun4 users (SunOS 4.1.1) have reported seeing the
>error:
>
>               xntpd: previous time adjustment didn't complete
>
>in their syslogs.  What would normally cause such a message?  Is it serious?


Thanks very much to everyone who responded to my question (both via e-mail
and directly to the net.)  The consensus seems to be that the Sun clock
is a very bad one.  I was already using 'tickadj -A' to set the value
of tickadj to an optimal value in the running kernel.  However, a couple
of other paramaters are also useful (and most likely necessary):

        tickadj -A -s -t 9999

The -s option sets the value of dosynctodr to zero in the running kernel.
This has the effect of telling the OS to stop trying correct the clock's
drift (the work is left for xntp!).  The -t 9999 option sets the value
of tick in the running kernel to 9999.  According to several of the responses
I received, this is a good value for most Suns.  However, I have not seen
a complete list.

Thanks again for the help.

=============================================================================
From: [e-mail] (Mike Iglesias)
Subject: Re: ntpdate: errors when trying to synch to other xntp hosts
Keywords: ntpdate xntp3

[e-mail] (Art Mulder) writes:
>  For the most part, everything runs fine, but on some of our
>  workstations we get: ``no server suitable for syncronization found''
>  when ntpdate runs.

Make sure those systems can convert hostnames to IP addresses at that point
(i.e. make sure everything necessary to use nameservers is up and running
if you are using them), and that any routing that needs to be setup is in
place before you run ntpdate.

> The only solution I have found is to to pick some different hosts for
> ntpdate.

Maybe those hosts can get to the servers that work but not the other ones,
as I mentioned above.

>ps: It would be really nice if some central version numbering scheme
> were set up for xntp3.  It would sure make it easier to track.

YES!  PLEASE!

=============================================================================
From: [e-mail]
Subject: Re:  NTP peers

chongo,

I do not have the resources to provide individual configuration advice
for a specific installation - there are many thousands of them now. The
ntpd (version 1) distribution has been obsoleted twice over and been
replaced by NTP Version 3. A comprehensive Unix daemon is available
in the compressed tar archive pub/ntp/xntp3.tar.Z on louie.udel.edu.
It includes scads of information on installation, configuration and
peer selection. Other files in the pub/ntp/doc directory on that host
contain probably more than you will ever care to know about timekeeping
in general and, in particular, the file clock.txt, which contains a
list of public stratum-1 and stratum-2 time servers. Happy chime.

Dave

=============================================================================
From: [e-mail] (William L. Jones)
Subject: Just a few small suggestions!


Thanks!

We really need a faq for comp.protocols.time.ntp.


When you talk about using tickad on a sun you need to mention that
if you are running Sun OS 4.1.3 you don't need the "-t 9999" on tickadj.

Bill Jones

=============================================================================
From: [e-mail] (Geert Jan de Groot)
Subject: Re: Reachability keeps resetting zero after a STEP

[e-mail] (Joey Pruett) writes:

>I just recently started trying to use ntp on my sun systems.  I've
>compiled the xntp3 stuff from louie.udel.edu and things kinda run.  The
>behavior I am seeing is that everytime a STEP is performed, all the
>servers I talk to have their reachability reset to 0 and everything
>starts over again.  This even happens to the LOCAL_CLOCK I configured
>into the server.  Any help would be greatly appreciated.  I don't
>understand much about ntp yet, so I am probably not understanding
>something...

I have the same problem, but after a note from Dave it now seems to be
solved. Dave, please correct me if I am wrong, and maybe it is a good idea
to include it in the notes files..

The first problem is that SUNs have too much tolerance on their clocks.
Because NTP requires removal of synchonisation to the built-in
NVram clock (that is where tickadj -s option is for, to reset dosynctodr).
Now your SUN really starts drifting, and ntp tries to get up with
that, but because the clock error is high (several hundreds of ppm),
NTP does not succeed at first, and it takes a few days to adjust.
In that time, the SUN will frequently loose synchonisation , which
you can determine by looking at the status words in your log file,
combined with appendix A of RFC1305.
Hence, it is a bad idea to have the SUN synchonize anything else.
Wait for things to stabilize first!

The approach I used is to start xntpd on a new machine (as slave - I didn't
want to confuse the server I used), wait for two or three days, and then
check /etc/ntp.drift. Because xntpd raises or lowers the drift value only a
few ticks per hour, at first xntp is not able to correct the frequency
error. After a while, the time error between your clock and the reference
gets higher and higher and xntpd starts to complain:
>08:21:56 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.177012563)
>08:23:00 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.248992682)
>08:24:06 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.248992682)
>08:25:08 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.404627085)
>08:26:12 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.404627085)
>08:27:16 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.404627085)
>08:28:20 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.577525616)
>08:29:24 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.757438898)
>08:30:28 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.759768605)
>08:31:34 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.757438898)
>08:32:36 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.757438898)
>08:33:40 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.757438898)
>08:34:44 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.757438898)
>08:35:48 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.757438898)
Then, after a while, some hold-off timer times out and the time is
SET, no longer ADJUSTED. This is what you see:
>08:36:52 xntpd: adjust: STEP 16.1.0.22 offset 0.821858644
As a result, xntpd declares itself invalid and starts to synchonize:
>08:36:53 xntpd: system event 5 status c043
>08:36:54 xntpd: peer 130.43.2.2 event 84 status 9024
>08:36:54 xntpd: system event 4 status c655
>08:36:54 xntpd: peer 129.189.134.11 event 84 status 9024
>08:36:55 xntpd: peer 127.127.1.5 event 84 status 8024
>08:37:56 xntpd: peer 16.1.0.22 event 84 status 9024
After a while, xntpd synchonizes again and declares healthy again:
>08:42:13 xntpd: system event 3 status 664
and the thing starts over again. In time, these events happen less and
less often, until the drift value is close enough that xntpd is able
to steer the local time within its limits.

The basic idea is to sit on your hands for a few days, don't use the
server (yet) to synchonize others, and see what ntp.drift does.

I find your steps quite huge. Did you run tickadj -As before you started
xntpd?

After that, your offset is probably still too large. Start ntpq, do 'rv'
and look for the frequency offset. Divide by 1000 to get the real
frequency error in ppm, which should be less than +-100 ppm.
Now, you should vary the 'tick' value of tickadj to make the frequency
error (the value in /etc/ntp.drift), or (rv / 1000), less than +-100.
You will find that xntpd synchonizes much more quickly - in my case,
it needed only one time STEP. Suitable values for tick are 9999 +-2
or so. I found that sun4/60's are nearly similar to each other,
sun4/280's too, but there is a severe difference between these families.
It seems that there is a difference in mechanism between sunos 4.1.2
and sunos 4.1.3, but I have not found the details in my news archive.

This is as far as I am now - I'm adjusting tick for various machines.
xntpd no longer complains about time STEPs.

I stress that this knowledge is not my wisdom - Dave Mills helped a lot,
and I am just describing the experience I got by following Dave's hints.
In return, I hope that this message helps others too. Would an xntp
guru care to correct my story? Then, it might be Americanized (I'm
no native English speaker, but you already figured that out :-),
and maybe this information can be added to the xntpd documentation.
I am glad I am not the only one that had the problems you have.
Dave, thanks!

Warning: clock hacking is very addictive. On the other hand, I find it
much fun, so you might want to become addicted too!

Hope this helps,

Geert Jan

=============================================================================
From: [e-mail] (Michael J. Corrigan)
Subject: Re: Preliminary FAQ -- send updates to [e-mail]

A question I have answered by email a couple of times is:
"My newly installed version 3 xntp can't talk to any of the systems
it used to talk to. What's wrong ?"

You need a line like:
peer    host.dom.top    version 2

if the host is still running version 2.

=============================================================================
From: [e-mail] (Wayne Folta)
Subject: Re: Preliminary FAQ -- send updates to [e-mail]

>Make sure you run tickadj on your Suns before you run xntpd.  Here's
>how we run tickadj:
>
>   tickadj -A -s -q -t 9999
>
>You can leave off the -t 9999 if you want.  We find that our Suns drift
>less with that setting.

I read in c.p.t.ntp that Sun OS 4.1 -- Sun OS 4.1.2 have an off-by-one
bug that requires -t 9999 to fix. Sun OS 4.1.3 and beyond do not have
this problem, is is said.
--


Wayne Folta          ([e-mail]  128.8.128.8)

=============================================================================
From: [e-mail] (Rick Thomas)
Subject: Re: Using xntp without radio clock or internet connection?
Keywords: clock ntp internet

[e-mail] writes...
> We would like to set up time synchronization for a network of ~500
> hp9000-700 workstations. Unfortunately we don't have a connection to
> the internet (yet) nor do we have a radio clock. Is there any way to
> fool xntpd into thinking it is a stratum 1 server?
>
> Other solutions or suggestions would be appreciated (I am also looking
> at timed).

Well, here's one way...

In xntp (both v2 and v3) there is a pseudo-radio-clock driver that uses
the CPU's own local clock as its time source.  Read the docs for how to
compile with this feature turned on.  (In v2 you set "-DREFCLOCK
-DLOCALCLOCK" in the Config file.  I'm not sure what you do for v3, but
it's probably pretty much the same.) That pseudo-clock can be
configured so that it appears to be at any given stratum from 1 to 15.
Pick one "master" system, and one "backup" system.  Configure the
"master" so that its local clock is at stratum 10 and the backup system
so that its local clock is at stratum 12.  The master and backup have
their ntp.conf files set up to talk to each other as "peer"s, and all
the rest of the systems' ntp.conf files use both the master and backup
as "server"s.  With that configuration, the master will free-run and
all other clocks on the local net (including the backup) will track the
master at stratum 11; unless the master goes down, in which case they
will track the backup at stratum 13 and the backup itself will
free-run.  You use different stratum numbers for the master and backup
so the clients don't have two equally attractive choices, each with a
different idea of what time it is.

Thanks to Cary Gray for pointing out that the master and backup need to
be separated by 2 strata, not 1.  The reason is (in Cary's words):

> If you configure the local clock for host A a stratum 6 and for B at
> stratum 7, and A and B peer, then B's peers are:
>   A at stratum 7 [sync'd to A's clock at stratum 6]
>   B's clock at stratum 7
> For any of the NTP implementations, B is almost certain to prefer the
> second peer, which will have lower dispersion and synchronizing distance
> (unless you've done some very careful work with the fudge factors).
>
> I learned this the hard way using ntpd back at Stanford.
>
>    Cary


When you finally get a radio clock, it will be at stratum 1 and will
automatically take over as the most attractive source.  If you connect
it to your "master", you don't need to change anything (except to turn
on the appropriate driver).  You can even leave LOCALCLOCK configured
on the master at stratum 10 as a backup to the radio clock incase it
goes down.  If you put the radio clock on another system, you need to
make the obvious changes to the ntp.conf files to have all systems
(including the master and backup) use that machine as (yet another)
server.


If you get an internet connection instead of a radio clock, then have
your master and backup talk (as clients) to a couple of stratum 1 or 2
hosts on the internet (for redundancy, use a different couple of
servers for the backup from the couple you chose to serve the master.)
Leave LOCALCLOCK configured at stratum 10 and 12 as backups incase the
internet connection dies.  Leave everybody else unchanged, as clients
of the master and backup machines.  That keeps the traffic to the
internet stratum 1 or 2 server down to a minimum.

Best of all is to combine the two approaches; have *both* an internet
connection *and* a radio clock.


That should do it.

Enjoy!

Rick
=============================================================================
From: [e-mail] (Robert L Ullmann)
Subject: Re: Using xntp without radio clock or internet connection?

I cringe every time I see someone talking about configuring a local-clock
(self-referential clock) at strata like 3 or 4. If you are going to
do it, use 10 and 11 (or similar); it will work perfectly well,
but you don't run the risk of confusing systems that can see your
clocks as well as _real_ strata 3 or 4 sync'd to active radio
clocks.

I'd like to see the code fixed to prevent configuring local-clock
at less than 10. Or better, increasing infinity to 31, and specifying
min local-clock as 16; so a strata of 15 or less implies _real_
time reference. (Whatever _real_ is! :-)

My implementation uses 31 as infinity; as long as the code is careful
not to adjust the clock using samples that had strata larger than the
(immediately) previous sample from the peer, you don't suffer bogus
adjustments as the servers wander out to infinity. (This is a good
idea regardless of the value of infinity.)

Writing an independent implementation to the written specification
without reference to the PD source is instructive; there are real
holes in the protocol specification, as well as interesting improvements
available to things like the filter algorithm. (Yes, I will be telling
about various things I've found as I get time to do it. :-)

Rob

--
Robert Ullmann        [e-mail]    [phone] x226
=============================================================================
From: [e-mail] (Joey Pruett)
Subject: What I've learned about sun clocks and ntp
Organization: Test Systems Strategies, Inc., Beaverton, Oregon

This is all my opinion about how things work (or should work) and are
by no means authoritative.  I assume that the reader understands how to
create the configuration file and have read about tickadj.

This is the procedure that I've come up with to get the clock on
a sun system working pretty well.  It is a sun 4/670 running
4.1.2.

# tickadj -s -a 5
    This stops the system from resetting the clock from the hardware
clock.  If you don't do this, ntp and the hardware clock fight over
the correct time.  It also sets the adjtime step to 5 usec which
allows ntp to make a change of 500 usec/sec.

# ntpdate server [server...]
    This will set the clock to a semi-sane value.  Try to use more
than 1 server.

# xntpd
    The ntp server (duh!).  Let it run for at least a day, if not
longer.  Over that time it should be able to figure out how bad your
clock is.  This value is recorded in the driftfile (usually
/etc/ntp.drift) and is updated once an hour.  Monitor this and when it
seems to have stabilized for a couple hours, you should be ready.  Kill
the ntp server when you're ready to fiddle with things.
    Now the value you will want to use for 'tick' is 10000 + int(drift/100).
So if your drift is 213.64, then tick should be 10002, -172.12 would be
9999.  Edit the driftfile and remove the hundreds part, so the examples
would be 13.64 and -72.12.  I decided that I like having a positive
adjustment, so I add 1 more to tick if the value is still negative, and
then update the driftfile to be 100+olddrift.  So, my example of
drift=-72.12, tick=9999 gets turned into drift=27.88, tick=10000.
    If the absolute value of drift is not > 100, then you can just use
10000 for tick.

# tickadj -s -a 1 -t <tick value>
# xntpd
    Run these and also update rc.local to do the same.

After doing this, ntp will be able to make change things up to
100 usec/sec and the changes can be as small as 1 usec.  This keeps
the time as accurate as possible by not accumulating adjustments
until large enough to call adjtime().

And now a question.  In the kernel, there is a variable called
'clkdrift' that looks like it might be a trim value.  It seems
like things would work much nicer if the kernel could always
be trimming the clock rather than having ntp adjtime() every
second.  Does anybody now how this variable is used?

Hopefully, I haven't made a horrible error in my method, or in
my description of it...

=============================================================================
From: [e-mail] (Sam Pierson)
Subject: Summary: NBS NIST PSTI WWV WWVB GOES
Organization: Sun Microsystems (UK) Ltd

Thanks to all who answered my post about these acronims.  I have
summarised all the info I received below in case anyone is interested
in using it in the forthcoming FAQ.  I make no claims to the accuracy
of the information, I just collated it.  Thanks go to Chris Polk, David
B. Brown, Ross Alexander and Ian Phillipps.

-Sam.

----


BIH    Bureau International d'Huere

    Organization in Paris France, that keeps track of world time.

GOES    Geosynchronous Orbiting Environmental Satellite

    A set of satellites that provides weather satellite imaging for
    the North American continent. GOES satellites also provide a
    timecode that is NIST-traceable and is uplinked by NOAA
    (operators of GOES) at Wallops Island, NC.  Can be received by
    very simple equipment. Carrier is around 137 Mhz.  Accuracy
    is in the lower milliseconds.

GPS    Global Positioning System

    A satellite navigation system usable for accurate timekeeping,
    Its accuracy range is normally about 100 nanoseconds and the 3D
    coverage is getting close to the desired 24 hours a day.

NBS    National Bureau of Standards.

    This is the old name for the NIST.

NIST    National Institute of Standards and Technology

    A department of the US Department of Commerce.
    Headquarters in Boulder, Co.
    Responsible for maintaining reference physical standards such
    as time, meter, kg etc.
    The civilian counterpart of the USNO (see below).

PSTI    Precision Standard Time Inc.

    A company that produces a WWV[B] tracking timepiece.

UNSO    United States Naval Observatory

    Keepers of UTC (Universal Coordinated Time).

WWV    Radio station call sign.

    American radio station run by the NIST that broadcasts standard
    time frequency (and weather ?) information on 2.5, 5, 10, 15,
    and 20 MHz from Fort Collins, Colorado.

WWVB    Radio station call sign.

    60Khz version of WWV.
    Sited in Washington DC (?)  [Actually Ft Colins CO]

WWVH    Radio station call sign.

    Hawaii station of WWV service.


---
   Sam Pierson -- European Support Services, SunSoft Inc. High Wycombe, UK.
        Internet: [e-mail]   UKnet: [e-mail]
         I do not speak for SunSoft, Inc or Sun Microsystems, Inc.

=============================================================================
From: John C Sager <[e-mail]>

Rick,
Thanks for the FAQ. here are some corrections.

> BIH    Bureau International d'Huere

>    Organization in Paris France, that keeps track of world time.


Bureau International de L'Heure
                        ^
I believe that this has now become part of the International Bureau
of Weights & Measures (IBWM), another acronym for the list.

> GPS    Global Positioning System

>    A satellite navigation system usable for accurate timekeeping,
>    Its accuracy range is normally about 100 nanoseconds and the 3D
                                             ^^^
>    coverage is getting close to the desired 24 hours a day.

Make that several hundred ns, due to the effect of Selective Availability.
The absolute maximum should be < 1us.
I believe the spec on |(GPS time - UTC) modulo 1 sec| is < 176ns for the
case where S/A is compensated (military kit).

> UNSO    United States Naval Observatory
   ^^?
>     Keepers of UTC (Universal Coordinated Time).

Not really. The IBWM keep UTC as a synthesis of UTC clocks kept by USNO
NPL (National Physical Laboratory (UK)), and other organisations in France,
Germany, Russia & other places. There is generally some small difference
between all these national standards. I understand GPS will be the vehicle for
significantly reducing these differences.

regards,
John

=============================================================================
From: [e-mail]
Subject: Re:  Need a reference clock

Dorian,

Tired ticker ncarfuzz.ucar.edu has come victim of oxide plow, while
clepsydra.dec.com has been rehomed to a VAX. Use DNS to resolve its
true address. Ticker dcn5.udel.edu has gone to the great clock in the
sky and several other fuzzbums unnoticed in the swamp have been
eaten by alligators. The remaining ones fuzz on, although some are
grossly overloaded (clock.sura.net and umd1.umd.edu). I would dearly
love to see the fuzzbums retired and replaced with modern silicon,
but for various reasons, squeaky time is not a priority issue with those
that count the beans. In any case and in order to avoid overheating
the tired old silicon and redline DMZs, we should all avoid pecking on
the stratum-1 servers, both fuzz and otherfuzz, unless prepared to
front for a biggish bunch of churlish clients.

Please note the file clock.txt changes on about a monthly basis, so
any file that "came with the distribution" is surely long of tooth.

Dave

=============================================================================
From: [e-mail] (Ken Stone)
Subject: Re: HP version of ntp wanted


> I need some assistance in locating a version of ntp/ntpd for HP-UX V8.x,
> would you be able to point me in the right direction.

The standard xntp3 code works just fine with the addition of a seperate
daemon (adjtimed) to compensate for the lack of adjtime(2).  Pick up
the code from louie.udel.edu.  I have it running on over 350 8.X HP-UX
machines on this site alone ... s300/s700/s800 all work.

  -- Ken

=============================================================================
From: [e-mail] (Rick Thomas)
Subject: Re: 3 or 9 Internet NTP servers?
Organization: Rutgers Engineering Supercomputer Lab

^% The DEC documentation says:
^% "If your site is connected to the Internet, you should configure three
^% (but no more than three) NTP primary servers at your site that
^% synchronize to three highly accurate (stratum 1 or stratum 2) hosts on
^% the Internet."
^%
^% I may be having a brain fart, but this seems ambiguous.  Does
^% each local NTP primary server use three different Internet servers or
^% the same three?

Well, one way of doing it is to have 3 onsite primaries (stratum 3, say)
connected to 4 offsite servers (stratum 2, say) as follows

onsite-1 is client of offsite-a, offsite-b, offsite-c,
    and peer to onsite-2, onsite-3
onsite-2 is client of offsite-a, offsite-b, offsite-d,
    and peer to onsite-1, onsite-3
onsite-3 is client of offsite-b, offsite-c, offsite-d,
    and peer to onsite-1, onsite-2

This spreads your load around and gives you a little extra redundancy, but
not enough to cause severe confusion.  Peering onsites with fellow-onsites
makes sure you get consistent time amongst them.

Enjoy!
Rick
============================================================================
From: [e-mail] (Wai Yat Wong)
Subject: Re: Help --- xntpd[122]: Previous time adjustment didn't complete ?
Organization: School of Computer Science, UTS

A great thank you to  Anthon Ouwendijk <[e-mail]>

I now have an answer .

Anthon emailed me and explained the following:

|> All my workstations here that are running 'xntpd -b'
|> occasionally have these console messages:
|>
|> xntpd[122]: Previous time adjustment didn't complete
|>

You have Sun workstations, haven't you?

Maybe this is what you are looking for ...

SunOS 4.1.x has a lousy software clock: clock ticks are lost,
and it contains other bugs too.
Therefore SunOS adjusts its software clock to the battery-backup clock
and this plays havoc with the operation of xntpd. (Two captains on
a single ship, fighting for clock-control).

So, on SunOS you have to call 'tickadj -s' (see man-page) after
booting. Tickadj -s turns off the kernel parameter dosynctodr,
that controls SunOS synchronizing to its hardware clock.
The lousy software clock will be adjusted by xntpd.

So .... add the following lines to your ntprc file:

if [ ! -x <your-path>/tickadj ]
then
        echo    "NTP error, file tickadj missing." >&2
        exit 0
fi
<your-path>/tickadj -s -q

Thanks again, Anthon , all the way from the Netherlands.

============================================================================
From: [e-mail] (Nick Sayer)
Subject: Re: Help --- xntpd[122]: Previous time adjustment didn't complete ?
Organization: The Duck Pond public unix: [phone], log in as 'guest'.

[e-mail] (Wai Yat Wong) writes:

><your-path>/tickadj -s -q

While you're at it, that ought to be

<your-path>/tickadj -Aqs

This will also have tickadj compute and install an appropriate value
for tickadj, which allows xntpd to work around a bug in most kernels
having to do with the precision with which adjtime()s are applied
to the clock. See notes.me for more info.

=============================================================================
From: [e-mail] (Rick Thomas)
Subject: Re: what are the /etc/ntp.drift units?

>> What are the units of the /etc/ntp.drift file value?  ...
>> What I want is some way to sanity check a drift value.  I have systems
>> that lose about 1.1 seconds per day when left to run on their own.
>> What might I expect the drift value to be?
>>
>> chongo <> /\oo/\

I heard a rumor that the units changed between xntp and xntp3.  The
rumor went on to say that in xntp (v2 of the protocol) the drift in the
drift file is to be divided by 4096 to get parts per million. I.E.
microseconds of drift per second of time.  The rumor went on further
and said that in xntp3 (v3 of the protocol) the units had changed so
that one could read the contents of ntp.drift directly as parts per
million.  I think (degree of verification now less than rumor) that ntp
(v1 of the protocol) used the same units as xntp (v2).

Nick Sayer <[e-mail]> sent me some corrections to my rumor...
%
% Not quite. The drift file under v2 is 4096 parts per unit, not per
% million. So divide by 4096 and multiply by 1e6 and you get
% parts per million.

And Louis A. Mamakos <[e-mail]> sent the following addition
%
% Off the top of my head, I believe that ntpd uses the same units as
% xntpv2 does.  The format of the file is slightly different, as I
% recall, as the last few computed samples (one per hour) are recorded.
%
% This is from memory; we run xntp3 now and I don't recommend ntpd for
% any new applications.

To which Dave Mills <[e-mail]> adds
%
% The units in the file are in ppm, but the units shown in ntpq are 1000 times
% that amount or in parts in 10^9. Life lurches on.

And Lars Mathiesen (U of Copenhagen CS Dep) <[e-mail]> adds

% Almost ppm. (I should know, I put it in myself.) The actual unit is
% 2**-20 (a pure number, or seconds per second if you like). I was also
% surprised by the multiply-by-1000 behaviour of ntpq, which is a legacy
% of the Fuzzball era, I think
%
% (The old (xntpd v2) code used a 64-bit fixed-point register. I think
% it was effectively in units of 2**-12, since it was shifted by
% CLOCK_FREQ and applied once every four seconds. That is, the value in
% the drift file grew by a factor of 256.)


There are 86400 seconds in a day, so 100 ppm would be 8.64 seconds per
day.

Rick

============================================================================
From: [e-mail]
Subject:  drift units...

The value in the drift file: I was talking of units. To convert the
value in the xntp v3 drift file, in units of 2**-20, to units of ppm
(10**-6), you have to _divide_ the number by 1.048576 (or multiply it
by 0.95367431640625). In other words, the value is about 5% high.

If I am right (remember, I am not totally certain of this) the older
implementations expressed the value in units of 2**-12. To get ppms,
divide by .004096, or multiply by 244.140625. Or just say that in the
old format, the number was 256 times smaller.

Lars Mathiesen (U of Copenhagen CS Dep) <[e-mail]> (Humour NOT marked)

============================================================================
From: "Louis A. Mamakos, NTP mailing list maintenance" <[e-mail]>
Subject: NTP mailing list vs NTP netnews


> Thanks, Louie!
>
> Incidentally, to what e-mail address should I send the once-a-month FAQ
> so that the ntp mailing-list gets it as well as the
> comp.protocols.time.ntp netnews group.
>
> Are they gatewayed?  It doesn't seems so, but I can't tell for sure.
> Perhaps you could write something for the FAQ on how readers of the
> netnews group can get connected to the mailing-list.  If you do, I will
> add something about the netnews group for readers of the mailing-list.

There is a one-way gateway which causes traffic sent to the NTP
mailing list ([e-mail]) to be injected into the
comp.protocols.time.ntp newsgroup.  This is being done at Apple by
Erik Fair.  If I can find some good bidirectional news <-> mail
gateway software, I may consider making a local gateway which operates
in both directions.

I encourage all interested parties to read the USENET newsgroup rather
than subscribe to the mailing list.

louie

AKA: [e-mail]

============================================================================
From: [e-mail] (Garrett Wollman)
Subject: Re: Previous time adjustment didn't complete
Organization: University of Vermont, EMBA Computer Facility

In article <9304201216.ZM25019@hansen> [e-mail] writes:
>What changes should make (if any) when xntpd (V3) issues the following
>syslog message:

> Apr 18 14:00:55 hansen xntpd[13203]: Previous time adjustment didn't complete

It really depends on the machine you're using.  My machine generally
prints it out only once a day, usually correlated with other system
activity (when I'm re-compiling my kernel, for example, or expiring
news), so I don't worry about it.

>How often to 'too often'?  What is 'normal' for a system where all is well?

I'll let others answer the first question.  `Normal' is probably `not
at all'; I believe that the messages in my system probably result from
bugs in the interrupt handling code, although I'm not absolutely sure
and I'm not enough of a hardware hacker to look at it and see what
it's doing when this happens.

-GAWollman

============================================================================
From: [e-mail] (Ian Dickinson)
Subject: Re: time going backwards
Date: 18 May 93 14:03:09 GMT

In article <[e-mail]> [e-mail] (Lindy Foster) writes:
>I expected the behaviour to be more like date -a, where the
>system clock is _gradually_ slowed down using adjtime so there is no
>backwards time jump.  This is really important to us, as we receive real
>time data which is date stamped on arrival, and a consistent forward flow
>of time is critical.

I'm making the assumption that it only does this relatively soon after
booting.  If this isn't the case, I think you may have other problems.

The best workaround is to run ntpdate as early as possible in the boot
sequence, sleep for however many seconds it would take for the adjtime
call to succeed, call nntpdate again to do some finer adjustment, sleep
again, and then start xntpd.  For instance (culled from README.solaris2):

  tickadj -s -a 1000
  ntpdate -v server1 server2
  sleep 20
  ntpdate -v server1 server2
  sleep 20
  tickadj -a 200
  xntpd

Your values for tickadj may need changing.

(BTW, the tickadj kernel variable doesn't exist under Solaris 2.2 - what
 should one be doing in this case???)
============================================================================
From: [e-mail] (Martin Lichtin)
Subject: SUMMARY: Weird NTP behaviour (well, maybe not)
Date: 3 Jun 93 14:22:47 GMT
Organization: Olsen & Associates, Zurich, Switzerland

My question (basically) was:

 > We have a DCF radio clock and are running xtnpd on machine A.  There's
 > also a machine B, not running xtnpd and time off by 250 seconds
 > relative to machine A. I then start up xntpd on machine B (with
 > /etc/ntp.conf containing: "server A") .

 > A (date;sleep 2) loop says:
 > Tue Jun  1 18:40:48 MET DST 1993
 > Tue Jun  1 18:40:50 MET DST 1993
 > Tue Jun  1 18:36:43 MET DST 1993
 > Tue Jun  1 18:36:45 MET DST 1993
 > And now, clocks have synchronized. But wasn't this a bit rude?

The common answer was that for time deltas greater than CLOCK_MAX =
128ms, the clock is stepped and then the PLL (Phase-Lock Loop) takes
over.

However, I'm still waiting for someone who knows a way to avoid this
behaviour. Imagine a machine that only receives NTP packets for a few
hours a day. Do I need to set tickadj to a higher value? Can I twiddle
NTP to be less precise and allow correcting bigger offsets?

Martin.
----------------------------------------------------------------------------
The Answers:

From: John C Sager <[e-mail]>
To: [e-mail] (Martin Lichtin)
Date: Wed, 2 Jun 93 12:18:50 BST

Martin,

This is the way xntpd is supposed to work. If the error between the
system clock and the reference derived from the peer(s) it is using is
greater than CLOCK_MAX (128ms) then the clock is stepped to get it to
within a few milliseconds, and then the PLL control takes over. I
suspect this is done because the PLL time constant is so long (some
hours) and underdamped to some degree, that it would take a long time
to settle, and the adjustment capability would be exceeded. With the
recommended value for tickadj, the maximum adjustment rate available
is 500us per second. Adjusting at this rate it would take about 5.5
days to remove a 240 second offset, and the daemon would try to
command far greater rates than this. In practice, the frequency error
measured by the daemon would ramp up to a limit of about 390 ppm where
the daemon assumes something is badly wrong and quits.

John C Sager                    Mail:    B67 G18, BT Labs
--------------------

From: Frank Kardel <[e-mail]>
To: [e-mail]
Date: Wed, 2 Jun 93 13:41:01 +0200

Please let the daemon run all the time. Then it will be able to keep
the time with 128ms and all is well. NTP is not designed for casual use.

Frank Kardel

============================================================================
From: [e-mail]
Date: 5 Jun 93 19:30:05 GMT

Rick & Co.,

A few comments on your faq compendium follow. Sorry I don't have the
photonic bandwidth to eyeball the ntp newsgroup directly.

All Sun4s I know of have the local oscillator frequency at least
100 ppm fast, so the -t 9999 argument to tickadj is almost always
required. It is a good idea to get this right, whether 9999 or
something else, as the residual error affects the actual jitter
of the clock, as well as the frequency error should the NTP daemon
be interrupted for some reason. It is always the case that dosynctodr
should be disabled. While I haven't laid paw to SunOS 4.1.3 yet,
I doubt it is any different than 4.1.1 in these areas.

Rob Ullmann mentions an untainted implementation ex spec. I would very
much like to hear of such adventures and what holes remain in the
spec. It will also help the case if and when the spec is advanced
beyond the present Draft Standard status. Frankly, my experience in
promoting the present status has left me rather disenchanted with
the standards process, so advancement is not high on my agenda.

I don't think you want to meddle with clkdrift; it causes the differenct
between the tod clock and system clock to be displayed, if more than
one tick apart. In fact, if dosynctodr is NOT reset, xntp will not work
at all.

Fixup on anachronisms: So far as I know, NIST is headquartered in
Gaithersburg, MD, WWV and WWVB transmitters are at Ft Collins, CO.
Conventional wisdom (as opposed to Politically Correct) is that
USNO keeps the time and NIST keeps the frequency, but each reads
each other's timekeeper's notices. As for GPS time relative to UTC
time, you need to be equally delicate on turf. GPS receivers keep
GPS time as coordinated within GPS and may not split the weenieseconds
with respect to UTC. Without the military codes, GPS users are not
expected to achieve accuracies much better than LORAN-C, allegedly
0.25 nm or well over a microsecond. Don't believe it; with a good
timing receiver, 5-7 satellite averaging, a decent local timebase
and occasional discipline to LORAN-C, I'm getting better than 100
ns almost all of the time. This is verified by cesium oscillator
calibrated to USNO and is much better than early civilian GPS
receivers.

Dave

============================================================================
From: [e-mail] (Christopher Jackson - Special Projects)
Date: 6 Jun 93 14:55:16 GMT
Organization: Sun Microsystems, Columbia MD

In article <[e-mail]> [e-mail] writes:
>All Sun4s I know of have the local oscillator frequency at least
>100 ppm fast, so the -t 9999 argument to tickadj is almost always
>required. It is a good idea to get this right, whether 9999 or
>something else, as the residual error affects the actual jitter
>of the clock, as well as the frequency error should the NTP daemon
>be interrupted for some reason. It is always the case that dosynctodr
>should be disabled.

This is not quite correct.  While our oscillators are not perfect
(otherwise there'd be no need for NTP, right? :-) ), the consistent
100ppm error is due to software, rather than hardware.  Previous
versions of SunOS 4.X had a bug where the real-time clock register was
initialized to one less than the proper value.  The clock interrupt
thus fired one tick too early, and the system clock gained an extra
1us every 10 ms.

>While I haven't laid paw to SunOS 4.1.3 yet,
>I doubt it is any different than 4.1.1 in these areas.

This bug (Sun Bug 1094383) is fixed in SunOS 4.1.3, under which
the -t 9999 adjustment should no longer be necessary.  (Yes, you
do still need to disable dosynctodr.)


Chris Jackson  <[e-mail]>

============================================================================
From: [e-mail] (Tony Luck)
Date: 8 Jun 93 17:42:11 GMT
Organization: Fujitsu Open Systems Solutions, Inc.

[e-mail] (Don Lewis) writes:
>I'm not so sure it is fixed.  Our two Sparc 2's are running 4.1.2,
>and with the  -t 9999 adjustment, they are off by 19ppm and 34ppm.
>Our 10/41 running 4.1.3 without the -t 9999 adjustment is off by 106ppm.
>This is a small sample, but the 106ppm error is more than I would
>have expected.

A few more data points about how far out some Sun4's crystals can be.  Most
of these are IPXen, with a couple of SPARCstation2's, and a 4/690 and 4/330.
All are running SunOS 4.1.2

    ntp.drift    tick
    =========    ====
    -89.83615    10000
    -73.36331    10000
    -72.51350    9998
    -66.32201    10000
    -64.02086    10000
    -62.21976    10000
    -55.62454    10000
    -54.74640    10000
    -50.99059    10000
    -6.39066    10000
    -4.19466    9998
    -1.12428    9999
    9.57497        9999
    12.04364    10000
    22.07689    9999
    39.67384    9999
    51.66208    9999

>From these numbers, it looks to me like 106ppm is well within the range of
speeds that Sun4 crystals actually run.

A while back somebody posted a suggestion of running xntpd for a few days,
then look at the drift file.  If the absolute value is too big (>100?) then
kill the xntpd daemon.  If the drift value is negative, you should reduce
'tick', if it is positive, then increase 'tick' ... add/subtract 100 to the
value in the drift file for every point that you change tick, then start a
new xntpd daemon.

Sounds like the FAQ should tell people to start at "-t 9999" on pre-4.1.3
systems ... but be prepared to tune a point or two on all Suns.

-Tony Luck

============================================================================
From: [e-mail] (Nick Sayer)
Date: 10 Jun 93 10:56:31 GMT
Organization: The Duck Pond public unix: [phone], log in as 'guest'.

[e-mail] (Don Lewis) writes:

>In article <1ut0gk$[e-mail]> [e-mail] (Christopher Jackson - Special Projects) writes:
>>This bug (Sun Bug 1094383) is fixed in SunOS 4.1.3, under which
>>the -t 9999 adjustment should no longer be necessary.  (Yes, you
>>do still need to disable dosynctodr.)

>I'm not so sure it is fixed.  Our two Sparc 2's are running 4.1.2,
>and with the  -t 9999 adjustment, they are off by 19ppm and 34ppm.
>Our 10/41 running 4.1.3 without the -t 9999 adjustment is off by 106ppm.
>This is a small sample, but the 106ppm error is more than I would
>have expected.

I think the bug was sun4c specific, but the fix was applied to all
Sun 4 platforms in 4.1.3. Which means that sun4ms running 4.1.3
need to have tick incremented by one. sigh.

The best thing to do is do it on an individual basis. If your clock
is off by more than 50 ms, increment/decrement tick until it isn't.

============================================================================
From: [e-mail] (Christopher Jackson - Special Projects)
Date: 13 Jun 93 15:26:00 GMT
Organization: Sun Microsystems, Columbia MD

In article <f4oiA#[e-mail]> [e-mail] (Nick Sayer) writes:
>I think the bug was sun4c specific, but the fix was applied to all
>Sun 4 platforms in 4.1.3. Which means that sun4ms running 4.1.3
>need to have tick incremented by one. sigh.

Well, it turns out that Mr. Sayer is correct; the bug is not completely fixed
for sun4m machines.

The clock initialization for sun4, sun4c, and sun4m platforms was broken in
4.1.2.  A fix was made to all three platforms for 4.1.3.  Unfortunately, the
sun4m clock is a little different from the sun4/sun4c clock, and the fix needs
to be a little different as well.  The result is that in 4.1.2, sun4 and sun4c
were 100ppm fast, while sun4m was 50ppm fast; in 4.1.3, sun4 and sun4c are no
longer broken, but sun4m is 50ppm slow.  (Since it's 50ppm, not 100ppm, you
can't really fix this with the -t flag.)

A bug has just been filed on this, and it will hopefully be fixed in a future
release of SunOS.  In the meantime, the exceptionally brave may wish to try
the following patch.

Notes:
    This patch is for sun4m machines running 4.1.3 only; sun4s and sun4cs
    don't need it, and applying it to earlier 4.X releases will probably
    result in a crash.

    THIS IS NOT AN OFFICAL SUN PATCH; if it trashes your system, melts
    your disks, or turns your hair green, don't complain to me or to the
    Answer Center.  Caveat Emptor.

The patch:
    cp /vmunix /vmunix.bak
    adb -w /vmunix
    startrtclock+2c?W 110007a0
    startrtclock+34?W 90122480
    startrtclock+3c?W 912a2009
    startrtclock+40?W 1000000
    startrtclock+44?W 1000000
    $w
    $q
    reboot


If anyone actually tries this, I would be interested to hear how much it helps.


Chris Jackson  <[e-mail]>

============================================================================
From: [e-mail] (Amos Shapira)
Subject: Re: help with ntp
Date: 26 Jun 93 16:04:34 GMT
Organization: Inst. of Comp. Sci., Hebrew University, Jerusalem, Israel

[e-mail] (Jean Mehat) writes:

   I would like which version of ntp, xntp etc... is the most current one?
   We are running a small network of sun4 on the internet (< 10 machines).
   I have been said that time synchronisation is an important issue in
   security. I am somewhat lost between various releases of Network Time
   Protocol. Can you give me a pointer to the most recent release (like a
   ftp site & directory) ?

   --
   Jean Mehat, universite de Paris 8 Vincennes a Saint Denis,
   [e-mail], (1) 49 40 64 03, (1) 49 40 67 83 (fax)

As far as I followed it,  the most recent *released* version is 3.1,  the
"home site" of xntp is louie.udel.edu directory /pub/ntp.
You will find there also some alpha releases of a newer version.

The drawback of this site is that it is located inside the U.S. and therefore
you can't take advantage of the DES code it can use (you still can have the
MD5 code).  A release with DES which is located outside the U.S. is available
on ftp.csc.liv.ac.uk file /hpux/Networking/xntp-3.1.tar.Z.  This is the one
I'm running a few months by now and it seems to work greate.

Cheers,

--Amos

============================================================================
From: [e-mail] (Nick Sayer)
Subject: Re: NTP for Mac?
Date: 6 Jun 93 16:40:17 GMT
Organization: The Duck Pond public unix: [phone], log in as 'guest'.

[e-mail] (Nick Sayer) writes:

>I remember hearing some time ago about an NTP control panel or INIT
>for Macs. Is this true? What's it called and where can I ftp it?
>Thanks in advance.

Thanks to Randy Bush who not only pointed me towards, but mailed
me a copy of "Network Time", a control panel that does exactly
that.

============================================================================
From: [e-mail]
Subject: Re:  Leap second?
Date: 30 Jun 93 20:00:25 GMT

The fuzzballs are now so overloaded that I can't reach in and set the
leap bits manually. Between the smoke and steam of the xntp-alpha
stuff, new radio drivers and busted radios, not to mention new kernels
with leap stuff built in, I decided my bandwidth for this particular
leap event had been exceeded. Most of the radio services you mention
already have leap-warning bits and at least some of the clocks (CHU and
WWVB) do decode them in xntp-alpha. The problem here is that I haven't
completed the xntp-kernel interface for the kernels I have modified to
handle the leap event correctly. Standard kernels will of course not
bump the time until at least one update has been seen from the source.

Dave
============================================================================
From: [e-mail] (Dan Warburton)
Subject: Re: ntpdate version 3.1 on HP-UX A.09.01 A 9000/715
Date: 7 Jul 93 16:28:08 GMT
Organization: FAA Technical Center, Pomona, NJ

[e-mail] (Dan Warburton) writes:

>[e-mail] (Ian Ringrose) writes:

>>I having problems getting "ntpdate" to work on a HP-UX 9 system, I have not
>>set up any config files, but have started "adjtimed".

>>When I do:
>>        # ./ntpdate 128.175.7.4
>>I get:
>>        ./ntpdate: no server suitable for synchronization found

>>When I do:
>>    # ./ntpdate -d 128.175.7.4

>Yes, it seems that is might work. I have the same problem. I have
>just tested with my Internet firewall down and things seem to work.
>There must be a back socket that needs access.

>Is there any one out there that Knows what port and protocal TCP or UPD
>this back channel might be? I'll check the sources, but would like
>confirmation of my guess.

OK, here's my answer: ntp uses a udp back port of 123 on my Internet fire
wall (a cisco router) my access list needed the following:


!ntp network time protocal
access-list 101 permit udp 0.0.0.0 255.255.255.255 155.178.0.0 0.0.255.255 eq 123


This allows udp access to port 123 from anywhere on the internet to any host
on my Class B address space.

P.S. Maybe this should go into the FAQ?
--
Dan Warburton [e-mail] [e-mail] [e-mail]

============================================================================
From: [e-mail] (Tom Dunigan)
Subject: Re: ntpdate version 3.1 on HP-UX A.09.01 A 9000/715
Date: 7 Jul 93 20:44:37 GMT
Organization: Oak Ridge National Laboratory

In debug mode, ntpdate uses a non-privileged port number for its "source
UDP port" to do the query.  When not in debug mode, ntpdate uses port 123
as its source port.  Some systems (Ultrix), or maybe its the xnptd version,
refuse to reply to the 123-port request.
--
    Tom Dunigan
    [e-mail]

============================================================================
From: [e-mail] (Adam W. Feigin)
Subject: Re: syslog() bogosity
Date: 29 Jul 93 13:32:36 GMT
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH

[e-mail] (Jim Jagielski) writes:

>[e-mail] (Ed McGuire) writes:

>>The virtually identical syslog code found in each
>>of these processes should be consolidated, but before I do that, has
>>it been cleaned up already in the alpha?

>Why not in the main ntp*.h include file do a:

>    #ifdef LOG_DAEMON
>    #undef LOG_DAEMON
>    #endif
>    #define LOG_DAEMON LOG_LOCAL0

>Or maybe put this in Config...


Ugh. Its in there already as of xntp-alpha. All you need to do is to
change the DEFS line in your config file, and add the following:

-DLOG_NTP=LOG_(insert your favorite syslog facility here)

Its not really documented in the Config file anywhere, and I can't
remember where I came across it, but it does work. I just checked, and
it looks like I gleaned this from the code in xntpd/ntp_control.c
(line 1724) and xntpd/ntpd.c (line 190).

                        /AWF
============================================================================
From: [e-mail]
Subject: NTP FAQ: update for Sony
Date: Thu, 05 Aug 1993 10:31:25 +0200
Sender: [e-mail]

A little while ago I posted a request for help to run xntdp on Sony News.
Everybody agreed the answer was worth an entry in the FAQ.

This is a summary of the answers I got:

The problem is that Sony boxes do not take care of leap seconds correctly.
xntpd seems to synchronize well, but the date program pretends the clock
is 14 seconds off.

The solution is to remove the MET file in /etc/zoneinfo with all its links
and to replace it with a good one (sun's for example) and then to
restart inetd.

If you are in another time zone, you might have to change some other files.

Thanks to:

Heiko Trautwein <[e-mail]>:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> hello,
> on our SONY Workstations ( mips and mc68030 ) we had this problem too,
> the clock differs 14 or 15 seconds from all the other clocks, if
> timezone is MET, if you change the timezone to e.g. GMT the clocks
> are in time.
> So I think the GMT timezone is corrupt and copied the MET file from
> one of our Sun's on the Sony, and clocks where synched.
>
>    Heiko

[e-mail] (John C Sager) &  [e-mail] (Tony Luck)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In article <230vca$[e-mail]>, [e-mail] (Tony Luck) writes:
> > [e-mail] (durand alain denis) writes:
> >
> > >I'm trying to install xntp-alpha on various machine on our network.
> > >It's just fine for sun's, but for sony mips, it's really wierd.
> >
> > I think that this was discussed a couple of months ago ... as far as I recall
> > the problem is that the Sony systems have a table of the leap seconds so that
> > that can try to be really clever about telling you the time.  As a result,
> > they have a different idea of how many seconds there have been since 1970.
> > This confuses xntp somehow (maybe its date conversion code doesn't match the
> > libc ctime() stuff?) ... and the net result is that xntp sets the time to
> > a value that ctime() says is some number of seconds out (depending on how
> > many leap seconds ctime() is trying to account for).
>
> NTP ticks UTC, as do most Unix boxes, so at each leap second, it, and the
> Unix clock, get stepped appropriately. This is explained at length by Dave
> Mills in rfc1305 pages 76-79.
> There was some discussion on this group some time ago as to whether NTP
> should tick TAI, and the corrections done for leap seconds in the same
> manner as timezone & DST corrections are currently done (as the Sony
> box seems to do). At the time I argued that the current system is more
> convenient for most users, and the small number who need TAI can do the
> reverse correction at their own expense.
>
> >
> > Can't recall whether anyone had a fix for this though ... if anyone does, its
> > probably worth an entry in the FAQ.
>
> I would agree an entry in the FAQ migh prevent future puzzlement.

    - Alain Durand.
============================================================================
From: [e-mail] (Alan Barrett)
Subject: Re: NTP for Novell????????
Date: 10 Aug 93 00:44:36 GMT
Organization: Elec. Eng., Univ. Natal, Durban, S. Africa

[e-mail] (Mark F. Vickers) writes:
> Is there an NTP client for Novell???

This question should be in the FAQ, but is not there.  I usually email
replies to this question, but will post this time.

I don't know of an NTP implementation for Novell, but I do know of two
ways of synchronising the times of Novell servers using the RFC 868
time protocol (commonly called "rdate").

* There is an RDATE NLM from Murkworks that allows the Novell fileserver
  to synchronise its time from an rdate server.  Available from
  ftp://netlab2.usu.edu/misc/rdate.zip

* Brad Clements' Charon mail/lpr gateway can synchronise its time
  from an rdate server, and can set the times of the attached Novell
  fileservers using some Novell method.  Available from
  ftp://omnigate.clarkson.edu/pub/cutcp/charon

--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
RFC822: [e-mail]
============================================================================
From: [e-mail] (Tony Luck)
Subject: Re: Problems with xntpdc and ntpq in xntp(3.1)
Date: 12 Aug 93 17:19:07 GMT
Organization: Fujitsu Open Systems Solutions, Inc.

[e-mail] (Christopher B. Moore) writes:
>well under control.  But I'm having trouble running ntpq and xntpdc to
>get a look at what's going on.  Both programs fail with the message:
>ntp/udp: unknown service.  Can someone suggest what I might have done
>wrong?

I think that "ntp" is one of the well known services that Sun forgot to
put in /etc/services.  Just add the line:

ntp        123/udp                # Network Time Protocol

to /etc/services (For some bizarre reason this file is controlled by
NIS (formerly yellow pages), so if you are in the unfortunate situation
of using NIS you need to add this line to /etc/services on your server
and run ypmake/yppush/whatever).

-Tony Luck <[e-mail]>

============================================================================
From: [e-mail] (Patrick Schoo)
Subject: Re: Problems with xntpdc and ntpq in xntp(3.1)
Date: 16 Aug 93 10:08:16 GMT
Organization: University of Limburg, Maastricht

[e-mail] (Tony Luck) writes:

>I think that "ntp" is one of the well known services that Sun forgot to
>put in /etc/services.  Just add the line:

>ntp        123/udp                # Network Time Protocol

>to /etc/services (For some bizarre reason this file is controlled by
>..

>-Tony Luck <[e-mail]>

Sun didn't forget to put ntp in /etc/services, they just use the wrong
protocol (tcp instead of udp). In my original services file this line
was included (SunOS 4.1.1).

ntp        123/tcp                # Network Time Protocol

Does anyone know if this is a bug, or if there is a specific reason for
this?

Patrick Schoo ([e-mail])

============================================================================
From: [e-mail] (Geert Jan de Groot)
Date: 13 Aug 93 20:48:26 GMT
Organization: Philips Consumer Electronics, Eindhoven, The Netherlands

[e-mail] writes:
>The offset looks too high. Note the frequency slowly climing, which
>suggests the usual problem with SPARCs. Your /etc/rc.local file should look
>something like this:

>if [ -f /usr/local/bin/tickadj ]; then
>        /usr/local/bin/tickadj -t 9999 -a 5 -s & echo -n ' tickadjusted'
>fi
>if [ -f /usr/local/bin/xntpd ]; then
>        /usr/local/bin/xntpd & echo -n ' xntpd'
>fi

>This assumes SunOS 4.1.1. I am told, but have not confirmed, that 4.1.3
>has a bugfix which removes the necessity for the -t 9999 above. Then,
>I am told that Sun 5.x has a new bug which requires -t 10001. Your
>mileage may vary.

I found the offset to be CPU-specific. That means, when I needed
to have one CPU replaced, I had to re-find the right 'tick' value
for that specific board. It looks like the clocks are just
made with a larger tolerance than NTP can handle.

For each box running xntp, I build a file /etc/ntp.tick that contains
the tick value. I have values between 9997 and 10001, just to keep
the offset between +- 100 ppm on 4/280, 4/490, 4/690, 4/60, 4/65..
For a new CPU, I just set ntp.tick to 9999, let xntp run a day,
change ntp.tick if the offset is out of range, re-start xntp,
and retry. This usually stabilizes withing a few days.
If the offset is much too high (>250ppm), I found that xntp does
not obtain lock at all. These are all 4.1.3 machines.

Geert Jan

============================================================================
From: [e-mail] (Russell Mosemann)
Subject: Re: NTP for VMS
Date: 24 Aug 93 19:32:28 GMT
Organization: Concordia College, Seward, NE

[e-mail] writes:

>I have been reading this group for a few months now and have never seen
>mention of a version of NTP for VAX/VMS. I also checked the archives at
>UDEL.EDU. Did I miss is or is there no version for VAX/VMS?

   There is no version that I know of unless you use Multinet.  I am
finishing a port of ntpdate to VMS.  I need to smooth out the code in
a couple of places and document it, but for the most part it is done.
When it is complete, I will submit it to the archives.  Watch this space
for further news.
   If I get really exicted some day, I might try to port xntpd to VMS,
but that won't happen for at least a year.
--
Russell Mosemann     Concordia College      Voice: [phone]
Computing Center     Seward, NE 68434       Fax:   [phone]
============================================================================
From: [e-mail] (Mike Iglesias)
Subject: Re: NTP for VMS
Date: 24 Aug 93 23:02:37 GMT
Organization: University of California, Irvine

Both Wollongong and Multinet support NTP for VMS.  Wollongong is ntp v1,
and I believe that Multinet is also.

--
Mike Iglesias                        Internet:    [e-mail]
University of California, Irvine     BITNET:      iglesias@uci
Office of Academic Computing         uucp:        ...!ucbvax!ucivax!iglesias
Distributed Computing Support        phone:       [phone]

============================================================================
From: [e-mail]
Subject: Re:  xntp problem
Date: 25 Aug 93 00:00:22 GMT

Wesley,

The ntpdc works with NTP Version 1 implementations (ntpd) and not
Version 2 nor Version 3 implementations (xntp, xntp3, xntp-jones).
The equivalent program for the latter implementation is xntpdc included
in the xntp3, xntp-jones distributions. This program also works with
the Version 2 implemenation. Having said this, the program of choice
to fondle v2 and v3 implementations is ntpq in the xntp3, xntp-jones
distribution. This program conforms to the NTP Version 2/3 specifications
rfc-1119, rfc-1305, respectively and should work with other implementations
now coming online. The xntpdc program is very implentation dependent and
nto likely to work with any other implementation.

Dave

============================================================================
From: [e-mail] (Dave Katz)
Subject: churchy.udel.edu
Date: 6 Sep 93 20:32:42 GMT

I did a little monitoring of churchy (a cisco IGS) which is filling in
at a peer address that was idle for some months.

In 20 minutes, 650 NTP requests were received from 106 hosts.

Three sites had seven peers chiming with churchy.

A number of the peers are running version 1 NTP.

Looks like mucho cruft out there...

============================================================================
From: [e-mail]
Subject: Novell server time module available
Date: 14 Sep 93 17:58:24 GMT
Organization: Penn State University

There is now a directory on FTP.OTC.PSU.EDU which contains
information and software for synchronizing time on Novell
Netware servers with a Network Loadable Module (NLM) that
uses the unix "rdate" protocol. This NLM will allow Netware
servers to synchronize their time to time servers (eg:
CLOCK.PSU.EDU) within one second of accuracy.

This is not an implementation of Network Time Protocol (NTP),
which could provide better accuracy. Novell has committed
to that effort through the Distributed Time Service (DTS)
portion of OSF's Distributed Computing Environment (DCE).
An announcement on that from Novell will probably not happen
before the first quarter of 1994. Delivery schedule is even
more uncertain at this point.
(Feel free to correct me if you know something more current. :-)

*I don't speak for Penn State, Novell, or anyone else... *

The following is an information file included in the directory:

--- enclosed file follows ---

Info on files in /pub/ntp/ms_dos/novell on ftp.otc.psu.edu.

rdatenlm.txt   This file. ASCII text.
rdatenlm.zip   PKZIPed (tm) RDATE.NLM and README.TXT. Binary file.

--- beginning of README.TXT (extracted from RDATENLM.ZIP) ---

This package contains an RDATE NLM for Novell Netware 386 (tm)
    +-------------------------------------------------------------------+
    |Permission is hereby granted for this archive to be distributed via|
    |BBS, Compuserve, Anonymous FTP and any other means so long as no   |
    |fee is charged for distribution and all components of this archive |
    |remain together.                                |
    +-------------------------------------------------------------------+
The RDATE NLM is Copyright (c) 1992 MurkWorks, All Rights Reserved.

RDATE.NLM  - 10/12/92

** This is free software **

MurkWorks has provided this NLM to the Novell user community at no charge.

Purpose:
    The RDATE NLM allows the supervisor to synchronize the time
    of a Novell NW386 file server with the time of a nearby
    Unix host (or any other host which supports the time protocol).

[...]
[eof]

============================================================================
From: [e-mail] (John C Sager)
Subject: Re: any reason for ntp/tcp service?
Date: 21 Sep 93 09:19:07 GMT
Organization: BT Laboratories, Martlesham, Ipswich, UK

In article <[e-mail]>, [e-mail] (Darrin P Cardani) writes:
> Several of our /etc/services files listed ntp as a tcp service only, or
> as a udp and tcp service. The ones that listed it as tcp only, didn't work,
> so I fixed them by changing it to udp. Is there any reason to include tcp
> service, though? I have seen it on 2 platforms so far.

SunOS 4 /etc/services files are/were all like this, probably due to a misunderstanding at Sun. Dunno about other manufacturers. As you say,
a change to udp will fix it.

John C Sager                    Mail:    B67 G18, BT Labs
Email:        [e-mail]            Martlesham Heath
Tel:        [phone]                IPSWICH  IP5 7RE
Fax:        [phone]                England
Disclaimer:    This is me, not BT.

============================================================================
From: [e-mail] (Paul Eggert)
Subject: Re: Puzzled about leap seconds
Date: 22 Sep 93 02:29:03 GMT
Organization: Twin Sun Inc, El Segundo, CA, USA

[e-mail] (Thomas Sandford) writes:

    I think it means that ntp maintains the clock as though leap
    seconds do not exist.

I'm not quite sure what you mean, but if you mean that NTP forgets
past leap seconds, you're correct.

    Therefore on a system running ntp your timezone file must *not*
    contain any leap second entries.

That depends on what you mean by ``your timezone file''.  If you're
maintaining an astronomical application synchronized with NTP, there's
a good chance you will need a leap second database (if NTP suffices at
all).  But if you're merely maintaining a Unix (or, more precisely, a
Posix.1) host, then you probably don't need leap second entries, since
Posix.1 pretends that leap seconds don't exist and this maps
conveniently into NTP's fire-and-forget leap second handling.

    Also could you enlighten my ignorance. What exactly is TAI?

The quick answer is that TAI is Temps Atomique International, i.e.
International Atomic Time.  UTC = TAI + (integral leap second corrections).

The exact answer is a bit much to cover in a Usenet article, but here's
my best shot.  TAI is established on the basis of clock comparison data
supplied to the Bureau International des Poids et Mesures by
timekeeping labs around the world.  It is a coordinate time scale
defined in a geocentric reference frame with the SI second as realized
on the rotating geoid as the scale unit, i.e. it is not a proper time
scale if you take relativity into account.  To find out exactly what
TAI is, see B. Guinot and C. Thomas, ``The establishment of
International Atomic Time'', BIPM Annual Report of Time Section 1, part
D (1989).  More accessible reports appear in Metrologia 24, 195-198
(1987), Metrologia 28, 57-63 (1991), and Proc IEEE 79, 894-905 (1991).

============================================================================
From: [e-mail] (Jean Beland)
Subject: Re: NTP-client for MAC
Date: 24 Sep 93 14:38:48 GMT
Organization: Hydro-Quebec

Another NTP client for Macintosh is "Network Time 2.0", from Peter
Resnick. Available by anonymous FTP at sumex (shareware).

--
Jean Beland                 | Institut de Recherche d'Hydro-Quebec
Chercheur / Research Worker | 1800 Montee Ste-Julie,
tel: [phone]         | Varennes, Quebec, CANADA.  J3X 1S1
fax: [phone]         | Internet: <[e-mail]>

============================================================================
From: [e-mail] (Charlie Mingo)
Subject: Re: NTP-client for MAC
Date: 26 Sep 93 04:56:50 GMT

In article <[e-mail]>,
Rick Thomas <[e-mail]> wrote:
>
>Seriously, could somebody put it up for anonymous FTP?  If I had a place
>to point to, I'd put a notice of it in the FAQ.


I posted a copy to mac.archive.umich.edu.  It should appear in a few days.

============================================================================
From: [e-mail] (Tim Seaver)
Subject: SunOS zs serial port delays
Date: 24 Sep 93 16:25:03 GMT
Organization: CONCERT Network

This may be old news to most of you running STREAMS kernel
drivers for radio clocks on Sun workstations, but I don't recall
it being mentioned before. In the course of tracking down a
30 millisecond variation in timestamps on our WWVB radio
clock PPS signal, I discovered that, by default, SunOS only
services the zs serial port receive buffers every 3 clock ticks.
There's an internal flag used with the mouse port that allows
immediate interrupts, but I could find no way to set it from
user mode (other than by patching the kernel with adb once the
port is open). What this seems to imply is that every radio clock
kernel module running under SunOS on the zs serial ports should
do a

putctl1(WR(q)->q_next, M_CTL, MC_SERVICEIMM)

in the module open routine to pass the MC_SERVICEIMM (service
immediately) flag to the zs serial driver. In the xntp3
distribution, the dcf77 driver does set this, but the other
kernel modules don't. Setting this flag dropped a 30 millisecond
variation in our PPS timestamps to under 100 microseconds and
quite often under 10 microseconds over 5-10 second intervals.

    Tim

============================================================================
From: [e-mail] (Piete Brooks)
Subject: Re: XNTP3 on a Sun-3
Date: 27 Sep 93 21:44:55 GMT
Organization: U of Cambridge Computer Lab, UK

In article <28739v$[e-mail]> [e-mail] (Ian Dickinson) writes:
>Could anyone provide correct values for Sun4m SunOS4 and Sun4d SunOS5 please?
* -20 for the former (well, that's what I use).

>I don't know how to calculate these values so far.
* The code I use (in my clock driver) just finds the time to read the clock.
* Old Sun4s increment the usec each time the clock is read, then suddenly
* jumps up 20ms. So this is a plausible kind of guess as to what it might
* approximate to ...


* Try it a few times, or better still, just keep reading the clock and printing
* the deltas.  If you have multicast, look at the code to check the idle time
* of an MBone mrouted -- it's tweaked to do go fast -- microtime makes quite a
* change :-)

/* Find the precision of the system clock by reading it */
#define    USECS    1000000
#define    MINSTEP    5    /* some systems increment uS on each call */
#define    MAXLOOPS (USECS/9)
static int ees_get_precision()
{
    struct timeval tp;
    struct timezone tzp;
    long last;
    int i;
    long diff;
    long val;
    gettimeofday(&tp, &tzp);

    last = tp.tv_usec;
    for (i=0; i< 100000; i++) {
        gettimeofday(&tp, &tzp);
        diff = tp.tv_usec - last;
        if (diff < 0) diff += USECS;
        if (diff > MINSTEP) break;
        last = tp.tv_usec;
    }
    syslog(LOG_INFO,
        "I: ees: precision calculation given %duS after %d loop%s",
        diff, i, (i==1) ? "" : "s");

    if (i == 0)        return -20 /* assume 1uS */;
    if (i >= MAXLOOPS)    return EESPRECISION /* Lies ! */;
    for (i=0, val=USECS; val > 0; i--, val /= 2) if (diff > val) return i;
    return EESPRECISION /* Lies ! */;
}

============================================================================
From: [e-mail]
Subject: Re: network time server recommendations?
Date: 27 Sep 93 18:35:02 GMT
Organization: Boston College

In article <[e-mail]>, [e-mail] writes:
>
> I'm interested in dedicated Network Time Servers, specifically their relative
> price/performance/reliability information.  I've seen an ad for Bancomm's
> Tymserve(tm) box in a recent trade journal, but have nothing to which to
> compare it.  Any help would be appreciated.  Since this question is likely to
> have been asked many times in the past, a reference to when it was last
> discussed would give me a place to start.
>
I guess I spoke/wrote too quickly.  I just found a list of timecode receivers
currently available on the market in CLOCK.TXT  Any experiences and/or
recommendations would still be welcomed.

Armand
---
Boston College Computer Center                    Internet: [e-mail]
140 Commonwealth Ave.                               Bitnet: armand@bcvms
Chestnut Hill, MA 02167
============================================================================

============================================================================
From: [e-mail]
Date: 1 Oct 93 18:33:07 GMT

Dave,

See the file clock.txt in the pub/ntp/doc directory on louie.udel.edu for
a comprehensive list of public primary and secondary servers, along with
advice on how to set up a local NTP subnet. Advice can also be found in
the doc directory of the xntp3.3.tar.Z distribution in the pub/ntp
directory on louie.

Dave

============================================================================
From: [e-mail] (Denton Gentry)
Subject: Re: tickadj -A on Solaris
Date: 4 Oct 93 17:55:02 GMT
Organization: Sun Microsystems Computer Corp

In article [e-mail], [e-mail] (Ian Dickinson) writes:
>That's the 'problem' - Solaris 2.2 has been fixed to work correctly.
>You only need to call tickadj with the -s flag to turn off dosynctodr,
>tickadj doesn't exist anymore and tick is correct.

  You can also turn off dosynctodr in the /etc/system file, by putting in a line as follows:
set dosynctodr=0
  (Just on general principles, to avoid mucking around in a running kernel with tickadj -s).

                Denny

============================================================================
From: [e-mail] (Peter Whisker)
Subject: Re: NTP for DOS?  (We've done everything else...)
Date: 12 Oct 93 11:02:03 GMT
Organization: Logica DCG Ltd.

In article <[e-mail]> [e-mail] (Tom Fitzgerald) writes:
>From: [e-mail] (Tom Fitzgerald)
>Subject: NTP for DOS?  (We've done everything else...)
>Date: Tue, 5 Oct 1993 03:22:29 GMT

>Macs and Novell servers are covered - but how about DOS clients?  Anyone
>have NTP client code for them?  Even a simple boot-time ntpdate equivalent
>would be welcome.

>This should probably be in the FAQ too, if someone has an answer to it.

Perhaps this might help ...

;*************************************************************************
;**        USING PDCLKSET TO SET THE PC SOFTWARE CLOCK        **
;*************************************************************************
;**                                    **
;** PDCLKSET sets the time and date of the PC clock using a TIME server.**
;** To do so, the following information is required:            **
;**                                    **
;** - This clients unique IP number.                    **
;** - The IP number of an UDP/IP time server (most Unix systems).    **
;** - The time zone offset from UTC (GMT) at this place.        **
;** - If daylight saving (summer) time is used, which algorithm to use. **
;**                                    **
;** All the above info can be supplied as arguments to PDCLKSET. If any **
;** of the first three are missing, it will send a BOOTP request to try **
;** to find the missing info. If you are not using BOOTP you probably    **
;** must use gateway and mask arguments too. Except for client IP number**
;** and network mask, arguments to PDCLKSET override BOOTP info.    **
;** Using a BOOTP server is highly recommended, freeware code exists    **
;** for Unix systems and MSDOS PCs.                    **
;**                                    **
;** BOOTP can not supply which dst algorithm to use; also, zone offset    **
;** can't always be trusted. So, in practice, zone offset and dst algo- **
;** rithm (if applicable) are required arguments. On the other hand,    **
;** these parameters will stay the same all around the year, no need to **
;** change the setup.                            **
;**                                    **
;** If PDCLKSET finds more than one time server (sum of arguments and    **
;** BOOTP fields) and the first one does not answer, it will try the    **
;** other servers. The same applies for gateways.            **
;**                                    **
;** It is very hard to get accurate info on all the dst algorithms used **
;** all over the world, so the one you choose, you should test out. Use **
;** the alter argument to add or subtract time and days, and check that **
;** the dst switch occurs correctly. When using the alter argument, the **
;** date and time is displayed as usual, but the PC clock is not set.    **
;** If you find any errors, mail me the correct info to my mail address **
;** below. If you want to, you can customize your own dst algorithm,    **
;** see detailed info below.                        **
;**                                    **
;** PDCLKSET talks to the network card via a packet driver. If you have **
;** more than one packet driver, it will use the first one (lowest    **
;** packet interrupt number) unless you use the pktintno argument.    **
;** I have only tested PDCLKSET with Ethernet or Ethernet simulating    **
;** packet drivers. I have one report that it works with S&K FDDI    **
;** interfaces, if so it should work for token ring too, but I've got    **
;** no confirmation on that.                        **
;**                                    **
;** Running through remote bridges or slip links may require longer    **
;** than default timeouts. Add the number of extra seconds you need    **
;** with the argument LongerTimeout= time.                **
;**                                    **
;** If you want to omit the "End of pdclkset..." msg, add Flag=128     **
;**                                    **
;** In AUTOEXEC.BAT you should first load the packet driver, then call    **
;** PDCLKSET. It is very small (13 kbyte) and executes fast, so you will**
;** not notice any delay. PDCLKSET is not memory resident and does not    **
;** use any CONFIG.SYS devices, so no memory is wasted. Use TERMIN.COM    **
;** if you want to unload the packet driver. See call syntax below.    **
;** Note: If you always log into a Novell server after a boot, you    **
;** don't need this program, the PC clock will be set from the server.    **
;** However, if you are the supervisor, use PDCLKSET+SRVTIME to set it    **
;** (available at msdos.ftp.sunet.se:pub/network/novelutl/srvtime).    **
;**                                    **
;*************************************************************************
;**        USING PDCLKSET TO SET A TIMEZONE VARIABLE        **
;*************************************************************************
;**                                    **
;** PDCLKSET can also assign the proper normal or dls timezone name to    **
;** an environment variable (TZ is used by most systems). Argument    **
;** "Zone= #" will assign numeric zones to TZ (like TZ=+0100). If you    **
;** want anything else, use the alternative syntax, e.g.        **
;** "Zone= tzone=MET,METDST" will set TZONE=MET or METDST.        **
;**                                    **
;*************************************************************************
;**        SYNTAX AND EXAMPLES FOR TIMESETTING            **
;*************************************************************************
;**                                    **
;**   (time is [- | +] [<hours>h] [<minutes>m] [<seconds>[s]] )     **
;**                                    **
;** pdclkset            (displays a usage message)    or    **
;**                                    **
;** pdclkset b[ootp]        (only if dst not used)    or        **
;**                                    **
;** pdclkset [o[ffset]=time]                        **
;**                                    **
;**         [d[aylightsave]=PAC | USA | CUB | CHIL | BRZ | GBR |    **
;**                 W_EU | M_EU | E_EU | LIBY | EGY | TURK |    **
;**                 ISR | IRAN | PRC | ROK | AUS | TASM |    **
;**                 NSW | LHI | NZE |                **
;**                 FrTime,FrWeekDay,FrDayOfYear,        **
;**                 ToTime,ToWday,ToDayOfYr,AddTime]        **
;**                                    **
;**         [z[onename]= # | varible=normalname,dlsname        **
;**                                    **
;**         [i[pnr]=n.n.n.n]  [t[imservers]=n.n.n.n[,n.n.n.n[,...]]]    **
;**                                    **
;**         [m[ask]=n.n.n.n  g[ateways]=n.n.n.n[,n.n.n.n[,...]]]    **
;**                                    **
;**         [p[ktintno]=hexnr]  [a[lter]=days,time]  [f[lags]=flagnr]    **
;**                                    **
;**         [l[ongertimeout]=time]                    **
;**                                    **
;**                                    **
;** All arguments to pdclkset must be on the same line, no continuation.**
;** For arguments to BAT files, use ":" instead of "=" and ";" instead    **
;** of "," .                                **
;**                                    **
;** Valid flags for this mode:                        **
;**   128 = half quiet (skip the End of pdclkset line if no errors)    **
;**                                    **
;** Examples:                                **
;**                                    **
;** pdclkset o= -1h d=M_EU z=#     (my IP nr and timeserver(s) from BOOTP)**
;**                                    **
;** pdclkset offs=6h dst=USA zonename= tz=CST,CDT  (sets TZ=CST or CDT) **
;**                                    **
;** pdclkset o=8h  d=PAC  ip=123.45.6.7  ts=123.45.6.8    (BOOTP not used)**
;**                                    **
;** pdclkset o=-9h30m t=1.2.3.4 i=2.3.4.5 g=2.3.4.1 m=255.255.255.0    **
;**                                    **
;**                                    **
;** Part of an AUTOEXEC.BAT file may look like this:            **
;**                                    **
;**    \net\wd8003e -w 0x7d 3 0x280 0xd000    (install packet driver) **
;**    \net\winpkt 0x7c 0x7d            (install winpkt driver) **
;**    \net\pdclkset o=-1h d=M_EU z=#        (set PC clock and TZ)    **
;**                                    **
;** If you don't want to keep the paket drivers in memory, add the    **
;** following line:                            **
;**                                    **
;**    \net\termin 0x7c            (remove packet drivers) **
;**                                    **
;** If you just need timesetting, use pdclksml instead of pdclkset.    **
;**                                    **
;*************************************************************************
;**        WHERE TO GET IT FROM                    **
;*************************************************************************
;**                                    **
;** Current version of PDCLKSET can be obtained by anonymous FTP from    **
;** ftp.lu.se:/pub/network/pdclkset/pdclkxxx.zip or from        **
;** msdos.ftp.sunet.se:pub/network/pdclkset/pdclkxxx.zip or from Novell **
;** server LUSTORFS/ARC:PUB\NETWORK\PDCLKSET\PDCLKxxx.ZIP        **
;** (Netware access only in Lund and around).                **
;** Major releases will also be available on wsmr-simtel20.army.mil and **
;** its mirror archive sites in the msdos.pktdrvr directory.        **
;**                                    **
;*                                     *
;* Jan Engvald, Lund University Computing Center             *
;* ____________________________________________________________________  *
;*   Address: Box 783            E-mail: [e-mail]     *
;*          S-220 07 LUND    Earn/Bitnet: xjeldc@seldc52         *
;*          SWEDEN          (Span/Hepnet: Sweden::Gemini::xjeldc)     *
;*    Office: Soelvegatan 18        VAXPSI: psi%2403732202020::xjeldc     *
;* Telephone: [phone]        (X.400: C=se; A=""; P=Sunet; O=lu;     *
;*   Telefax: [phone]            OU=ldc; S=Engvald; G=Jan)     *
;*     Telex: 33533 LUNIVER S                         *
;*                                     *
;*************************************************************************



Peter Whisker
============================================================================
From: [e-mail]
Subject: Re:  Looking for NTP for SVR4
Date: 12 Oct 93 01:51:44 GMT

Ash,

Yes, the latest xntp3.3 has a SVR4 port. There is quite a bit of
information in the various README and man pages scattered through the
directories. Most directories have READMEs describing the contents.
The build process is mostly automated, unless you have an oddball
Unix port. For even more information, see the pub/ntp/doc directory
on louie.udel.edu.

Dave

============================================================================
From: [e-mail] (Barry Schaede)
Subject: Re: Looking for NTP for SVR4
Date: 12 Oct 93 19:04:10 GMT
Organization: U. of Az. Center for Comp. & Info. Tech.

In article <9310112134.AA07630@fender>, [e-mail] (Ashvini Nangia) says:
>
>tex deleted...
>        I'm also interested in using a "radio-clock" as the external
>        time source. If you have any information or tips as to where
>        I can get the hardware (who sells it in the US) that would
>        be very helpful.
>


We purchased the UTS-10, which is a radio receiver with display and an
RS-232 port from Odetics.  Their address is:

    Odetics - Precision Time Division
    1515 South Manchester Avenue
    Anaheim, Ca. 92802-2907
    Phone [phone]

============================================================================
From: [e-mail] (Amos Shapira)
Subject: clockdiff - measure difference in clock among UNIX machines
Date: 19 Oct 93 17:58:48 GMT
Organization: Inst. of Comp. Sci., Hebrew University, Jerusalem, Israel

Hello,

Here is a small programme to measure the difference in the clocks among
machines across an Internet network.

It consists on just one file so I didn't bother to package it or anything.

It is also available for anonymous ftp on host ftp.huji.ac.il file
/pub/network/clockdiff.c.gz (in Gzip format).

I don't know how accurate this programme is,  will appreciate any feedback.

Read the comments at the beginning for more info.

Bye,

--Amos
[[ It was 500 lines long, so I deleted it -- get it from FTP or send mail
to Amos -- Rick]]
============================================================================
From: [e-mail] (Rick Thomas)
Date: Fri, 22 Oct 93 17:27:03 EDT
Subject: RE -- What I've learned about sun clocks and ntp

In a previous article, [e-mail] (Joey Pruett) says --

%>Let it run for at least a day, if not longer.
%>Over that time it should be able to figure out how bad your
%>clock is.  This value is recorded in the driftfile (usually
%>/etc/ntp.drift) and is updated once an hour.  Monitor this and when it
%>seems to have stabilized for a couple hours, you should be ready.
%>Kill the ntp server when you're ready to fiddle with things.
%>
%>Now the value you will want to use for 'tick' is 10000 + int(drift/100).


I have a couple of comments based on talking with a friend of
mine who has a Solbourne with a particularly horrible clock.

First, the formula Joey gives is appropriate for xntp version 3, only.
The units of the number reported in the drift file changed between
version 2 and version 3.  For those of us still running version 2 (or
-- horrors! -- version 1) there is a different formula.

The version 3 "drift" value is reported in part per million.  "Tick" is
parts per 10000, so the "100" in Joey's formula comes from
    1000000/10000 = 100

(As a side note, the "parts-per-million" is really "parts per 2^20", so
the "real" value of the denominator should be 104.8576, but who's counting?)

The version 1 and 2 "drift" value is in parts per 4096.  "Tick" is still
parts per 10,000, so we use 4096/10000 = 0.4096 as the denominator in
these cases.

Hence, for ntp (v1) and xntp (v2), the correct "tick" value for use in
the "tickadj -t <tick>" is 10000 + int (drift/0.4096)

Second, you can tell if the drift value has stabilized by looking in
your /var/adm/messages file (or wherever else you have configured the
syslog deamon to put messages from xntpd) for hourly historical drift
values.  This advice is independent of which version of the software
you are using.

Rick

============================================================================
From: [e-mail] (John A. Dundas III)
Date: Sun, 14 Nov 1993 13:25:13 -0800
Subject: Macintosh NTP Client

Could you please add the following to the NTP FAQ?  Thanks...John Dundas

Another NTP client for the Macintosh is 'NTP Client' by John Dundas.  This
shareware is available at a number of archives; use archie to search for
'macntp'.  This software features the ability to use NTP over either UDP/IP
or AppleTalk.  (Special servers are required for AppleTalk.  The author
currently has servers implemented for Macintosh, VAX/VMS (AppleTalk for VMS),
and A/UX.  Contact the author for more details at [e-mail].)

============================================================================
From: [e-mail] (Torsten Duwe)
Subject: Re: xntpd 3.3a on Linux: stuck?
Keywords: tickadj, Linux, PC
Date: 24 Nov 93 13:35:34 GMT
Organization: CSD., University of Erlangen

>>>>> "HPA" == H Peter Anvin N9ITP <[e-mail]> writes:
[...]
    HPA> However, when /etc/ntp.drift reached the value -100.0000 is got
    HPA> firmly stuck, [...]

Yes, +-100 ppm is the limit, as you might know. One of the boxes I run Linux
on (a 486dx33, OPTI cs) gets as bad as -330 ppm. How do I know ? tick
adjustment - see below...

    HPA> tickadj just gives me "The value of tick is silly", this is after
    HPA> making a link from /vmunix to /usr/src/linux/zBoot/zSystem.

Right - this would be the way to do old-fashioned, ugly /dev/kmem-ing in
Linux, but even if you don't get errors it still wouldn't work. tick gets
reset to 10000 every tick :-(. Looks like you're another customer for the
hwtickadj for PCs I am (about) to write. It is going to do outb()s to adjust
the divider value in the timer chip. Temporary workaround: fix the divider in
linux/include/linux/timex.h (line 67:CLOCK_TICK_RATE) in steps of 100 (the
resolution that gets fed into the divider). +100 compensates for approx.
-83.8 ppm drift. After recompiling and booting the new kernel you should be
fine.

Hope that helps

    Torsten
---
 Torsten Duwe      [e-mail] | /etc/init: respawn failed.
 Friedrich-Alexander-Universitdt Erlangen-N|rnberg | fork license for
 Informatik IV (Betriebssyteme, verteilte Systeme) | uid 0 has expired.

============================================================================
From: [e-mail] (Kim H|glund)
Subject: Re: HP problem with ntp
Date: 30 Nov 93 08:45:57 GMT
Organization: Department of Computer Science, U of Copenhagen

[e-mail] (Darrin P Cardani) writes:
>I have a handful of hp's running hp_ux90 which are losing sync like crazy
>for some reason. We have several hp's running hp_ux90, which are running
>fine. For some reason these few machines (all on different subnets, all
>able to reach their broadcasters) are losing sync several times a day.
>Has anyone heard of this, and does anyone know of a solution? They're logging
>several thousand messages a day. Any help would be greatly appreciated.

Several people (including myself) have experienced this with xntpd v3.3.
For the time being I believe the solution is to use xntpd version 3.1.

--Kim
============================================================================
From: [e-mail] (Scott Reynolds)
Subject: Re: HP problem with ntp
Date: 30 Nov 93 19:36:46 GMT
Organization: Plexus Corp. -- Neenah, Wisconsin

In <[e-mail]> [e-mail] (Kim H|glund) writes:

>[e-mail] (Darrin P Cardani) writes:
>>I have a handful of hp's running hp_ux90 which are losing sync like crazy
>>for some reason. [...]

>Several people (including myself) have experienced this with xntpd v3.3.
>For the time being I believe the solution is to use xntpd version 3.1.

I have been running xntpd-3.3b for the last week with no ill effects on both
the 400 series HP-UX 9.0 and 700 series HP-UX 9.01 platforms.  You might
consider giving this a try.  Don't forget to install (and run!) adjtimed.
Note that the config script will understand the OS as v8, not v9.
--
Scott Reynolds
Assistant System Adminstrator
Technology Group, Inc.
[e-mail]

============================================================================
From: [e-mail] (Philip Gladstone)
Subject: Re: request for example kernel PLLs
Date: 12 Dec 93 23:20:50 GMT
Organization: Citicorp

Duane Voth ([e-mail]) wrote:
: So, can anyone send me an example of a proper adjtime() (or ntp_adjtime())
: system call?  Maybe even something with a PLL attached?  We are running a
: USL SVR4 kernel here.  Please, no actual copyrighted code.

You might like to look at the Linux kernel that includes a PLL clock
implementation that seems to work. Look at your local Linux archive
for sources or try tsx-11.mit.edu

--
Philip Gladstone - Consultant
Citicorp Global Information Network
I don't speak for Citicorp. I presume that somebody else does!

============================================================================
From: [e-mail] (Duane Voth)
Subject: Re: ntp black box?
Date: 10 Dec 93 22:56:13 GMT
Organization: TANDEM Computers, Inc (MPD)

In article <[e-mail]>, [e-mail] (Brad Huntting) writes:
> I'm looking for a dedicated "plug-n-play" stratum 1 ntp server to
> attach to ethernet or fiddi.
>
> Does such a beast exist?

Yes.  I know of two from one company, there should be a couple more companies
offering these things too...

The Bancomm division of DATUM INC. sells:

    a) Tymserve 2000 LAN Time Server         $ 8,500
    b) BC700LAN GPS Network Time Server      $12,700

You can get Global Positioning System receivers for both (prices quoted
include GPS) to make it truely worthy of a stratum 1 server: accuracies
quoted are less than +/- 2 usecs of UTC.  If you have an IRIG time code
source near by you can skip the GPS option and knock off $2k-$4k.  The
BC700 appears to free-run at 0.5ppm with an oven option to go to 0.002ppm!
(thats right 2x10e-9!)  Can't seem to find a ppm spec on the Tymserve -
it may not free-run at all.

Bancomm is in San Jose, CA   1-800-348-0648

I have not used one of these yet but hope to soon.
============================================================================

Date: Wed, 22 Dec 93 16:58:34 EST
From: [e-mail] (Rick Thomas)
Subject: Re:  faster scrolling on raw SPARCstation screen

Here is the NVRAM patch that speeds up scrolling on Sun4c bare consoles
by copying the FORTH console driver into (fast) RAM, instead of allowing
it to execute out of (slow) ROM.  It incidentally fixes (most) of the
dropped interrupts that cause "last adjustment didn't complete".

Heed the warnings!  Do NOT use this with early ROM revisions!

Enjoy!

Rick

PS -- don't despair if you have a ROM rev below 2.2.  Latest rev ROMs
can be purchased from SUN for a cost of about US$50.

> Date: Sun, 2 Jan 1994 21:47:41 -0800
> From: Nick Sayer <[e-mail]>
>
> I didn't see any mention of this...
>
> You can make a vast improvement both in the clock accuracy and the speed
> of the ROM console (at the cost of 200K of RAM or so) with this (works
> only with boot ROM rev 2.0 or higher, which should be available on
> any sparc apart from the sun4_ kernel architecture. I just got an
> upgrade for my SS1+ that bumped it up from 1.mumble to 2.9!):
>
::::::::::::::: cut here and make an executable file ::::::::::::::::::::::
#! /bin/sh

echo 'Be VERY careful -- install this ONLY on machines with PROM revision 2.2'
echo 'or higher.  This will cause very unpeasant hangs in lower revs.  "Very'
echo 'unpleasant" means "refuses to boot and may require a service call to'
echo 'get it fixed."  On PROM revs equal to or later than 2.2, you can use'
echo 'the "<L1>-N" sequence to set all EEPROM values back to factory default.'
echo '(Hold down the <L1> key and the "N" key while the power is turned on.)'
echo ''
echo 'got that?'
echo 'Answer "yes" to continue.'

read answer
if [ "$answer" != "yes" ]
then
exit 1
fi

eeprom 'nvramrc=probe-all install-console
ramforth
: cache-page dup pgmap@ cacheable swap pgmap! ;
up@ cache-page
here origin do i cache-page pagesize +loop
banner'

eeprom 'use-nvramrc?=true'

exit 0
::::::::::::::: cut here and make an executable file ::::::::::::::::::::::
============================================================================

From: [e-mail] (Ken Stone)
Subject: Re: adjtimed dies on HP-UX 9.0 (s800)
Date: 23 Dec 93 21:29:30 GMT
Organization: Hewlett Packard, San Diego Division

In article <[e-mail]> [e-mail] (John O'Shaughnessy) writes:
>I've installed xntp 3.1 on an HP 9000-845 running HP-UX 9.0.
>It builds just fine, and when launched manually, runs just fine.
>I've included the following in the /etc/netbsdsrc startup file:
>
>  /usr/local/etc/adjtimed -r
>  /usr/local/etc/xntpd
>
>Both startup OK, but adjtimed dies immediately, with the following line
>in syslog:
>
>  Dec 22 18:06:16 a00308 adjtimed[188]: read message: Identifier removed

Geez ... maybe this oughta go in the FAQ ?

In a stock 9.X s700/s800 systems, there is a bug in DIAGMON that causes
it to trash all message queues when it starts up.  The possible solutions
range as follows ....

    a. Get the DIAGMON patch from the response center ....

    b. Start adjtimed/xntpd shortly after DIAGMON (ie not in netbsdrc)

    c. Just don't run DIAGMON (ie comment it out in /etc/rc)

And life will be much better ...

  -- Ken

============================================================================

From: [e-mail]
Subject: Culturally correct chime
Date: 1 Jan 94 21:37:43 GMT

Folks,

A problem previously mentioned and often casually ignored has come to
the point I must vigorously protest; and, I suspect my problem may
be generic to a bunch of other places. It has to do with the use of
private, unannounced server resources. I have several private time
servers here used for experiment and local service, one of which is
being hounded by over 50 unapproved rascals, 12 of which from the
same net(!). That breaks several of the culturally correct expectations
spoused in the file clock.txt frequently announced to this list. I'd like
these rascals to go away, especially as this host is used for all kinds
of experiments and sometimes tells awful time. I'd rather not be more
specific; but, if anybody is punching net 128.4 clocks other than
public primary servers rackety.udel.edu (128.4.1.1) and churchy.udel.edu
(128.4.1.2) and secondary server louie.udel.edu (128.175.1.3), I`d
sure like them to contact me first.

On a related matter, cultural correctness calls for no more than two
clients from any net to gang up on any single primary server. On rackety
I see as many as 19 clients from the same net! It may be time, as I
had to do in the fuzzballs, to put code in the NTP daemon that enforces
this. It's a terrible idea in the first place, since it introduces a
serious hazard, should the primary server go berserk. In fact, rackety
has a dead radio right now and is operating at stratum 2 by chiming
another stratum-1 server. If that radio comes bum, all of our servers
back out to a WWVB radio, which is not working correctly either. See
what I mean?

Finally, note that we have on the order of 1000 clients now honking our
three servers, quite a few running old versions (1 and 2) of the
protocol. The problem is, these versions do not scale back the rate of
chime once the local clock has stabilized. There would be a considerable
reduction in network loads (about a factor of 16) if these old versions
could be upgraded to version 3 (xntp3.3b.tar.Z on louie.udel.edu in the
pub/ntp directory). This is one of those problems that we tend to
ignore until, one day, the network just freezes up.

Dave

============================================================================

From: [e-mail] (John K Scoggin Jr)
Subject: Re: Question: How to time sync VAX/VMS and Ultr
Date: 9 Jan 94 15:13:01 GMT
Organization: Delmarva Power & Light

In article [e-mail], [e-mail] writes:
> A (hopefully) quick question for the "Time-Gods":
>
> We have a small isolated network, with a mix of VAX 4000's (running VMS) and
> DECstation 5000's (running Ultrix 4.2/4.3a).  The VAXes are all getting
> IRIG-B time signals and having their internal clocks sync'ed to that.
> We would like to have the VAXes distribute their time to the Ultrix
> machines, especially to a database server machine.  Is there a simple way
> to accomplish this?  Accuracy to less than one-half second is desirable, but
> less than one second is probably OK.  I looked that the latest NTP (v3) stuff,
> but it is mostly greek to me, and I don't see anything that looks like it
> will compile on the VAX/VMS systems.


We use TGV Multinet - it has a version 1 NTP implementation.  Old, but it is
functional.

    - John

============================================================================

From: [e-mail] (Nick Sayer)
Subject: Re: Culturally correct chime
Date: 12 Jan 94 14:27:57 GMT
Organization: The Duck Pond public unix: [phone], log in as 'guest'.

[e-mail] (Terry Kennedy, Operations Mgr.) writes:

>[...] I'm not sure what would be a good, inexpensive clock, though
>[the two seem rather mutually exclusive 8-].

Does this mean it's time for a CHU preach? :-)

A CHU receiver/modem is so durn close to being free I can't believe
there aren't more of them among the stratum 1 population.

Rather than bellow on and on, anyone who doesn't know about CHU,
write me and I'll fill you in. The reader's digest version is:

shortwave radio + 3 chips + Sun running 4.1.3 + 1 serial port = +/- 1-2 ms.

============================================================================

Date:     Thu, 13 Jan 1994 15:40 -0500
From: [e-mail]
Subject:  Re: Preliminary FAQ -- send updates to [e-mail]

Concerning the question "NTP on VMS", it will be appreciated if you
could add our product TCPware from Process Software as another alternative
for supporting NTP on VMS.

--
Hiroto Shibuya

Process Software Corporation
Framingham, MA


============================================================================
From: [e-mail] (Jeffrey Mogul)
Subject: Re: Unix boxes with only timed
Date: 14 Jan 94 03:05:41 GMT
Organization: DEC Western Research

In article <[e-mail]> [e-mail] (Hiroto Shibuya) writes:
>|>Speaking in generalities, all modern UNIXen will *support* NTP, though few
>|>if any have it *bundled* with the OS. You'll have to obtain, compile and
>|>configure it. Your machine will support NTP just fine.
>
>Of course.  Please read 'support' as 'vendor support'.   I'm interested in
>this information since there is a demand to run timed on non-AIX box
>connected to network primarily consists of AIX, which is currently using
>timed for clock sync.  I just wanted to find out if there is any other
>machine with timed as 'vendor supported' clock sync mechanims so I can
>have wider range of testing to interoperate with 'vendor supported' timed.

DEC "supports" both NTP and timed as bundled parts of the ULTRIX
and OSF/1 operating systems.  From the Software Product Description
for OSF/1:

 Network Time Protocol

 DEC OSF/1 provides the Network Time Protocol (NTP) Version 2 to syn-
 chronize and distribute the time for all machines in a network envi-
 ronment. The time synchronization daemon, xntpd, is used to distribute
 time to all machines in a network.

 Time Synchronization Protocol

 DEC OSF/1 provides Berkeley's Time Synchronization Protocol (TSP). TSP
 synchronizes the time of all machines in a network without ensuring
 the accuracy of the time that is provided.

TSP = timed, I believe.

I suspect that most other Unix vendors also support timed.

-Jeff
============================================================================

From: [e-mail] (Per Hedeland)
Subject: Re: Unix boxes with only timed
Date: 15 Jan 94 12:05:02 GMT
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden

In article <2h5s95$[e-mail]> [e-mail] (Ian Dickinson) writes:
>In article <2h5265$[e-mail]>,
>    [e-mail] (Jeffrey Mogul) writes:
>>I suspect that most other Unix vendors also support timed.
>
>Most do.
>
>SunOS 4.x does (but no NTP).

That's news to me - I certainly had to install it from 4.3BSD sources
(+ some additions) back when I started to take an interest in correct
timekeeping on our Suns (before I had learned about NTP:-), and the
only timed I can find on my current SunOS 4.1.3 system is in
/usr/local/etc, where it certainly wasn't put by Sun:-).

>Miraculously, Solaris 2.x ships with neither NTP or timed.

Seems that Sun's idea of timekeeping remains "use rdate every now and
then"...:-(

============================================================================
From: [e-mail] (Jerry Scharf)
Subject: Re: Latest/cheapest in GPS clocks ?
Date: 21 Jan 94 03:32:53 GMT

Your timing is perfect. My GPSWorld issue with the annual
GPS receiver survey arrived yesterday. Here are some of the
vendors that list clock support specificly. As Dave Mills
said, you have to be a bit careful if you are after the full
accuracy. I have left out a >$5K units, and have listed some
OEM units, but it may be impossible for you to buy one of
the OEM units, so I will list them last. I just gave one
listing per company. This is a personal transcription of a
manufacturers survey, so lots of things may not be just
right, or omitted.

One plug. We have the TrueTime unit, and have a driver ready
for it. We like it alot.

Jerry Scharf

Banncom        bc627AT        $3695    pc board
  6541 Via Del Oro, San Jose, Ca 95119 [phone]

Datum        9390-52000    $4000    rack
  1363 S State College Blvd, Anaheim, Ca 92806 [phone]

Odetics        GPSync        varies    rack
  1515 S Manchester Ave, Anaheim, Ca 92802 [phone]

Spectrum Geophysical GPS Time-Machine $2795  box
  1900 W Garvey Ave S., Ste 200, West Covina, Ca 91790 [phone]

Stellar GPS    model 100    $2495    box
  800 Charcot Ave, Ste 110, San Jose, CA 95131 [phone]

Trak Systems    8821 GPS clock    $3500    rack
  4726 Eisenhower Blvd, Tampa FL, 33634 [phone]

TrueTime    GPS-TMS        $3495    box
  2835 Duike St. Santa Rosa, CA 95407 [phone]

----------
Magellan    GPS Brain Timing ???    oem board
  960 Overland Ct, San Dimas, Ca 91773 [phone]

Trimble        Acutime II    ???    pod oem?
  645 N MaryAve, Sunnyvale CA 94086 [phone]

============================================================================
From: [e-mail] (Rick Thomas)
Subject: Re: Newbie questions.
Date: 29 Jan 94 22:46:06 GMT
Organization: Rutgers Engineering Supercomputer Lab

[e-mail] (Robert Sexton) writes --

robert> Hello All,
robert>
robert> After reading c.p.t.n for a while, I have decided to throw some
robert> basics on the table.  I have read the FAQ, but it seems awfully
robert> slanted towards those people on BSD with access to the net.

That's cause the people who have the answers are that kind of people.
I'm afraid it's unavoidable.  To try to redress the balance, I'll
include this question and my answers in the FAQ.  (Ahhh! The power of
being an editor!)

robert> 1.  Do you have to meet an accuracy requirement to be considered
robert>     Stratum 1?  Or is it enough to be connected to a radio clock?
robert>     I think I can use CHU to get accuracy to about 1 ms.

One millisecond is just fine for a stratum 1 clock.  As they say --
"Come on in, the water's fine!"  And I might add, "And welcome! We can
always use another stratum 1."

robert> 2.  I have the schematics for Marcus Leech's CHU reciever, but
robert> are there less expensive oftions for getting radio time signals?
robert> Can anybody recommend an inexpensive, easily interfaced radio
robert> clock?  I have considered using WWV, but it looks like the signal
robert> may be harder to work with.

Nick Sayer also has schematics for a CHU receiver he designed.  His
address is [e-mail] .  Take a look at them and see if they
meet your needs better.

robert>
robert> 3.  What sort of time signals are the ntp sources designed to
robert> work with?  will I have to write my own stuff for use with CHU?
robert> SCO UNIX does have adjtime(), so I have the basic tools
robert> available.

Well, for your purposes, Nick Sayer has contributed a CHU driver for
the current xntp (v3) that talks to his receiver.  It may also talk
to other CHU receivers as well.  In any case, it shouldn't take too
much work to make it talk to them.

robert> 4.  Is there any software out there for non-tcp time update?  I
robert> would like to offer time signals to BBS's in my area.

Not that I know of.  Why don't you write some?

robert> Thanks for your time.

And thank you for your questions.  They are good ones.

robert> Robert Sexton

Rick

============================================================================
From: [e-mail] (John C Sager)
Subject: Re: It's Official: GPS Anti-spoofing Is Now on Continuously
Date: 17 Feb 94 09:48:23 GMT
Organization: BT Laboratories, Martlesham, Ipswich, UK

In article <[e-mail]>, [e-mail] (Rick Thomas) writes:
> > 1. CONDITION: A/S WAS ACTIVATED ON DAY 031 (JAN 31 94) AT 0000 UTC.
> > DUE TO THE 8 DEC 93 DECLARATION OF INITAL OPERATIONAL CAPABILITY
> > (IOC) THE P-CODE WILL NOT NORMALLY BE AVAILABLE TO USERS WHO DO NOT
> > HAVE VALID CRYPTOGRAPHIC KEYS (IAW FEDERAL RADIONAVIGATION PLAN 1992).
>
> Can somebody who knows tell us all what this means to us?
> If I get a good answer, I'll put it in the FAQ.
>

GPS signals carry two sets of codes, the C/A code, with a chip rate of
1.023 MHz, which is the one used by civilians, and also helps the
military receivers to lock on quickly. The other code is the P/Y code,
with a chip rate of 10.23 MHz. This is used by military receivers
and is capable of higher location accuracy. The P code is published,
and was in use hitherto. The Y code is an encrypted version of the
P code, and is now used instead. To use it you need a P-code receiver
with a decrypter, and a source of keys from the DoD (I assume they are
security-conscious enough to change them periodically!). The term
'anti-spoofing' is used because it is now all but impossible for anyone
to create false GPS signals which could fool a military receiver.

This is probably of little consequence to most NTPers, as we all use
C/A code GPS receivers, ie they only use the civilian code. (Anyone want to
own up to using a P/Y code receiver for timekeeping?).

John C Sager                    Mail:    B67 G18, BT Labs
Email:        [e-mail]            Martlesham Heath
Tel:        [phone]                IPSWICH  IP5 7RE
Fax:        [phone]                England
Disclaimer:    This is me, not BT.

============================================================================

Date: Fri, 4 Mar 94 14:11:13 EST
Return-Path: [e-mail] (Kenneth Herron)
Subject: Re: Preliminary FAQ -- send updates to [e-mail]
Organization: University of Kentucky, Dept. of Math Sciences

The two entries that mention "-t 9999" on suns could be more clear
that this is only right for the sun4 (i.e., sparc) architecture.  The
standard tick value on sun3's is 20,000 so -t 9999 makes it run at
just about half speed (which is so terrible that xntp 3 gives up :-)

============================================================================
From: [e-mail] (Alexander Dupuy)
Subject: Re: NTP in demand dialup network
Date: 4 Mar 94 00:25:16 GMT
Organization: Columbia University Department of Computer Science

I posted a somewhat longish message a month or so ago about running
NTP over demand-dialup IP.  You can check the ppp-users archive at
ftp.morningstar.com, or the NTP mailing list archive (is there one?).

The brief summary is that you should use xntpdc, not ntpdate,
synchronized with a few secondaries (if you can teach your demand dial
software not to bring up the link just because there's an NTP packet
which wants to go out).  Set up a local clock "peer" at stratum 5 or
6, so that xntpdc will stay synchronized when the link is down.  Link
up times of only slightly more than 5 minutes appear to be sufficient
to keep my IPX within 50 msec of our secondaries, once the drift rate
is accurately calculated (this may take a day or two).

============================================================================
From: [e-mail] (John C Sager)
Subject: Re: DST switching
Date: 10 Mar 94 09:08:57 GMT
Organization: BT Laboratories, Martlesham, Ipswich, UK

[e-mail] (KESSELER GEORGES) writes:
> Hi,
>
> how does an unix machine decide when it has to change to DST? As I understand xntp does not provide
> this information to unix as it works in UTC. Is there an algorithm or a table in unix for DST?

As you say, the system clock keeps UTC time (on a correctly configured
system). The kernel & library routines which provide timezone and
DST information refer to one of a set of files in a directory
somewhere. On Sun systems this is /usr/share/lib/zoneinfo, but it may
be elsewhere on other systems, eg /etc/zoneinfo. The method of
selecting the file differs. On BSD-type systems a hard link is made
between the particliar zone info file and a filename 'localtime' in the
zoneinfo directory. On SVR4-type systems, an environment variable, TZ, is
set to the name of the file to be used. The file contains information about
the zone offset from UTC, and the dates of DST changes. Look at the man pages
for zic(8), zdump(8), & tzfile(5) for more info.

============================================================================
From: [e-mail] (Hans van Ouwerkerk)
Subject: PC sync solutions needed (Reply)
Date: 23 Mar 94 11:52:47 GMT

Norman H. Chang from Hewlett-Packard Laboratories asked:
>
> We would like to sync PCs running MS-DOS and Windows3.1 to 0.1 sec
> across LAN/WANs.
> What solutions exist out there?
>
Up to now I saw no answer to this question.

We use LAN Manager, sold to us by Hewlett-Packard :-)

The server runs xntp and when people login to the fileserver for LM
(HP 9000/817) the PC is synchronised with the server. I suppose this
is accurate to 0.1 sec, but of course the clock of the PC will drift
away in the course of the day.

Maybe this can help Norman if he uses LAN Manager.

============================================================================
From: [e-mail] (Mike Slade)
Subject: Re: PC sync solutions needed (Reply)
Date: 23 Mar 94 14:36:26 GMT

A similar solution exists if you are running PCNFS. As part of the bootup sequence and after PCNFS is started, do an 'rdate' command to your favorite NTP machine. Once again, the pc will drift away from the correct time.

============================================================================
From: [e-mail] (Frank Kardel)
Subject: Re: please answer: slewing the time on a "local clock" master server.
Date: 26 Mar 94 10:29:27 GMT
Organization: CSD., University of Erlangen

[e-mail] (Duane Voth) writes:


>In article <[e-mail]>, [e-mail] (James R. Hendrick) writes:
>>
>> Hi,
>>     Pardon me if this is a trivial question. I have a machine running
>> xntp that runs a bit fast. Recently, someone "pointed out" that my servers
>> clocks were all 5-10 minutes fast. I have looked and cannot seem to find a way
>> to do the equivalent of: "date -a -600". I tried this first, and it seems
>> that xntp won't let this adjustment occur (maybe it is due to date's use of
>> adjtime??) I am running "tickadj -A -s" on boot time before starting xntp.

From the manual (doc/xntpd.8):

     The local clock driver uses only the fudge time1  parameter.
     This  parameter  provides read and write access to the local
     clock drift compensation register.  This value, which  actu-
     ally  provides  a  fine  resolution speed adjustment for the
     local clock, is settable but will remain unchanged from  any
     set  value  when  the clock is free running without external
     synchronization.  The fudge time1 parameter thus provides  a
     way  to  manually  adjust the speed of the clock to maintain
     reasonable synchronization with, say, a voice time announce-
     ment.   It  is actually more useful to manipulate this value
     with the xntpdc(8) program.

Thus you can use the "fudge 127.127.1.x time1 x.xxx" command to change
the speed of your clock to gradually get in sync with reality.
(You must have configured keys and passwords in order to be able to
use remote configuration from xntpdc. If you didn't do that you have
to re-start xntp anyway with a new config file.)

There is another parameter which will set the total offset of the
ntp clock (time2). This will allow to correct for the absolute error.
The comment in the code indicates that this method works best if the
daemon was compiled with SLEWALWAYS.
By looking at the code I got an initial impression that it might even
work without SLEWALWAYS compiles in, but no guarantees here.

So to sum up:
    - You must have configured xntpd for remote configuration if
      you want to avoid re-starting it.

    - xntpdc: fudge 127.127.1.x time1 x.xxx
      will modify the drift rate of the local clock and thus allow
      you to gradually get in sync with reality (semiautomatic
      process - you have to figure out the intrinsic drift of your
      system)

    - xntpdc: fudge 127.127.1.x time2 x.xxx
      will (hopefully) change the system time to match reality.
      You still have to figure out the intrinsic drift.
      This is not tested and might not do what you and i expect.

    - get a real reference clock and forget the problem above
      (sorry - but I had to mention that 8-)

Frank Kardel ([e-mail])

============================================================================
From: [e-mail] (Frank Kardel)
Subject: Re: lower stratum host is terminated
Date: 25 Mar 94 21:00:41 GMT
Organization: CSD., University of Erlangen

[e-mail] (Tomi Masahiko) writes:

>Running xntpd in these environment, strange behaviour was observed.
>Problem was that when offset exceeded approximately 1000 seconds,
>xntpd of host_B (stratum 2) was terminated, and never recovered.
>(Actually this is not confined to broadcast mode, it also occurs
>in both client/server and peer mode.)

>We would like to know
>
>    (1)if this matter is specified,

Yes, its the CLOCK_WAYTOOBIG define in include/ntp.h.

>    (2)if so, whether it is possible to change the "critical offset value
>      (this time 1000s)" and it is unique to hp-ux.

No it is common for all normal xntp configurations on all platforms.

You can change it if you want (you have the source). An error of
more than 1000 secs is very unusual so exiting is a valid option
on such misconfigured systems (initial time zone configuration errors or
wacky hardware clocks or long downtimes).

There is a compile time option to avoid the exiting of the daemon when
the time exceeds CLOCK_WAYTOOBIG.

Define BIGTIMESTEP to keep xntp running even if the local clock is off by
more than CLOCK_WAYTOOBIG seconds.

============================================================================
From: [e-mail] (Frank Kardel)
Subject: Re: NTP client?
Date: 26 Mar 94 09:51:58 GMT
Organization: CSD., University of Erlangen

[e-mail] (V Menayang) writes:

>Frank Kardel <[e-mail]> wrote:
>>
>>Well, then use ntpdate from the xntp distribution and throw the rest
>>away.
>>

>Thanks, to you and others who responded to my query.
>I finally decided to get the whole xntp package and compile
>the ntpdate utility.  BTW, perhaps because how I configure
>the compile, I can only query NTP V3 servers.  Is this an expected
>behavior of the ntpdate V3?

Yes, unless you specify "-o <version>" on the command line. Version
3 is the default. If you want to query version 2 servers just
do a "ntpdate -o 2 <hosts>".

============================================================================
Subject: NTP internet survey
Date: 14 Mar 94 15:50:34 GMT
Organization: CSD., University of Erlangen

Here are the results of the latest NTP network survey.
The NTP synchronisation network was scanned via NTP control messages.
This survey just shows the ntp hosts reachable from the
University of Erlangen in the time frame below.

NTP synchronisation net statistics
==================================

Information reflects the state of the net
as reachable from
   University of Erlangen-Nuernberg, Germany.
It is based on information collected
 from  Thu Mar  3 10:39:22 GMT 1994
 to    Mon Mar 14 15:15:02 GMT 1994
The most recent NTP host was discovered
       Mon Mar 14 15:15:02 GMT 1994
The database reaches back to
       Thu Mar  3 10:39:22 GMT 1994

Number of hosts:    6774 OK  out of 21148 queried
   Strati:   S-1:   73,  S-2: 1867,  S-3: 4834,  (higher strati have not been considered)
   Versions:  v3: 4516,   v2: 2258,
   Bad hosts:
      Timeout on connect:  11565
      Protocol error    :     9

Hosts at Stratum 1:    v3:   64,  v2:    9,
Hosts at Stratum 2:    v3: 1288,  v2:  579,
Hosts at Stratum 3:    v3: 3164,  v2: 1670,


Analysis per toplevel domains:

                   Stratum 1          Stratum 2          Stratum 3      Bad Hosts
Domain          Total   v3   v2 |  Total   v3   v2 |  Total   v3   v2 | Timeout Protoco
---------------------------------------------------------------------------------------
ARPA         :     0     0    0 |     1     0    1 |     3     2    1 |       0       0
AT           :     1     1    0 |    15    15    0 |     3     2    1 |      37       0
AU           :     2     2    0 |    43    32   11 |   112    29   83 |     363       0
BE           :     0     0    0 |     8     7    1 |    28    28    0 |       6       0
CA           :     3     3    0 |    63    40   23 |   229   156   73 |     314       0
CH           :     2     1    1 |   123    46   77 |   186    82  104 |     835       1
CL           :     0     0    0 |     3     2    1 |     1     1    0 |       2       0
COM          :     8     7    1 |   246   187   59 |   292   169  123 |    1402       2
DE           :    14    14    0 |   233   142   91 |   738   364  374 |     674       0
DK           :     0     0    0 |     8     6    2 |    29    24    5 |     108       0
EDU          :    10     6    4 |   433   286  147 |  1902  1399  503 |    3039       0
ES           :     0     0    0 |     7     6    1 |    44    44    0 |       8       0
FI           :     0     0    0 |     2     2    0 |    15    14    1 |      32       3
FR           :     1     1    0 |    15    13    2 |    39    30    9 |     104       0
GB           :     0     0    0 |     1     1    0 |     0     0    0 |       0       0
GOV          :     9     8    1 |   151    69   82 |   144   117   27 |     512       0
IE           :     0     0    0 |     5     5    0 |     7     7    0 |      42       0
IL           :     1     1    0 |     1     1    0 |     5     5    0 |      17       0
IS           :     0     0    0 |     4     0    4 |     0     0    0 |       0       0
IT           :     0     0    0 |     3     2    1 |    12    11    1 |      26       0
JP           :     1     1    0 |    37    27   10 |   125    64   61 |     101       0
LU           :     0     0    0 |     1     1    0 |     0     0    0 |       2       0
MIL          :     0     0    0 |    26    21    5 |    64    48   16 |     215       0
MX           :     0     0    0 |     2     2    0 |     3     3    0 |       7       0
MY           :     0     0    0 |     2     2    0 |     3     3    0 |       3       0
NET          :     7     7    0 |    70    54   16 |    85    81    4 |      96       0
NL           :     1     1    0 |    47    40    7 |   120    51   69 |     257       0
NO           :     0     0    0 |     9     9    0 |   253   121  132 |     209       0
NZ           :     0     0    0 |     3     2    1 |     0     0    0 |       1       0
ORG          :     2     0    2 |    16    13    3 |    11     8    3 |     226       0
PL           :     0     0    0 |     2     2    0 |     1     1    0 |       4       0
PT           :     0     0    0 |     4     4    0 |     5     4    1 |       9       0
SE           :     1     1    0 |    22    19    3 |    18    13    5 |      55       0
SI           :     0     0    0 |     3     3    0 |     1     1    0 |       4       0
SU           :     0     0    0 |     3     2    1 |     0     0    0 |       2       0
UK           :     9     9    0 |   223   205   18 |   283   244   39 |     791       2
US           :     0     0    0 |     1     1    0 |     0     0    0 |       7       0
ZA           :     0     0    0 |     0     0    0 |     1     0    1 |       4       0
[UNRESOLVED] :     1     1    0 |    31    19   12 |    71    38   33 |    2036       1
seahawks     :     0     0    0 |     0     0    0 |     1     0    1 |       0       0
---------------------------------------------------------------------------------------
*TOTAL*      :    73    64    9 |  1867  1288  579 |  4834  3164 1670 |   11565       9

Following domains only had not responding hosts:
  BG, CZ, HR, SG, TH, lepton, pentium, righton.

The "top level domains" seahawks, lepton, pentium an righton are a
result of misconfigured reverse address translation information.

Frank Kardel & Rainer Pruy
============================================================================
From: [e-mail] (Frank Kardel)
Subject: Re: DST switch time
Date: 21 Mar 94 20:01:06 GMT

[e-mail] (KESSELER GEORGES) writes:

>Hello,
>I have the following machines syched via ntp: ultrix, AIX, HP-UX, SCO, TandemUX
>The big question is now: will they all switch to DST at the correct time?
Ok, frustrating answer time:
    Ask your vendor whether their timezone library works correctly
    and how it is configured correctly.
    The DST switch is not a matter of NTP. Its a matter of
    the timezone code in the library anf its configuration.

This question is the yearly fun part. Which vendors/sysadmins did it
right this year in the current OS version ?

Actually I don't know which OS will do it right in what configuration.
One thing is sure - NTP does not have anything to do with it 8-). NTP
just chews on UTC. The only problem UTC introduces is the leap seconds.
So June 30th will be the time where we all sit and watch the leap
second and what it will do to our receivers an the leap second code in
xntp 8-).
============================================================================
From: [e-mail] (Per Hedeland)
Subject: Re: please answer: slewing the time on a "local clock" master server.
Date: 29 Mar 94 22:25:20 GMT
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden

In article <[e-mail]> [e-mail] (Frank Kardel) writes:

[ lots of good stuff about how to tweak xntpd to keep better
  time when synced only to the local clock ]

>Thus you can use the "fudge 127.127.1.x time1 x.xxx" command to change
>the speed of your clock to gradually get in sync with reality.

Back before we had Internet access, I used this technique with very good
results - of course, to avoid having to do a lot of boring measurements
and calculations, I made a little script 'xntpdadj' to do them for me:

"Xntpdadj will, given an observed deviation from real time, and
knowledge ... about the time elapsed since the last time of agreement
with real time, a) adjust the clock (slowly) to agreement with real
time, and b) set a new time1 value that should keep the clock in better
agreement in the future."

I have put this script along with some info etc up for anon ftp in
euagate.eua.ericsson.se:/pub/unix/networking/xntpdadj.shar - note
however that it was written for, and has only been tested with, V2 xntp
- it should be possible to modify it for V3 though (it *does* need to be
modified).

I also eventually combined this script with a program that dialed up one
of those time-via-modem places to get a good offset from real time, and
ran it from cron every 6 hours, feeding the offset into xntpdadj if it
was > 50 ms - which it actually rarely was after a while (this was with
the clock of a good old VAX 11/750, sitting in a cooled computer room,
though...).

--Per Hedeland
[e-mail]  or
[e-mail]  or
...uunet!erix.ericsson.se!per

============================================================================
From: [e-mail] (Frank Kardel)
Subject: Re: lower stratum host is terminated
Date: 30 Mar 94 12:09:33 GMT
Organization: CSD., University of Erlangen

[e-mail] (Tomi Masahiko) writes:


>In such cases that the host whose local clock was without
>battery is booted (which means there is no guarantee that
>offset is under 1000s),

>       (1) do we need to adjust the local clock manually?
>          (I mean, the only way to avoid the problem mentioned
>           before is to insert "ntpdate" in the /etc/rc.local
>           start up script?)
This is one solution which might fail if ntpdate doesn't find
any hosts suitable for synchronisation. In that case it will
not correct the clock and the daemon would still give up.

>       (2) Otherwise, xntpd has a drive doing it automatically?
>       if yes, I would like to know how to configure.
It would if the offset is less than CLOCK_WAYTOOBIG. There is, however,
a compilation option where xntp will not give up on large offsets.
Compile xntpd with -DBIGTIMESTEP and xntp will set the local clock
to whatever time it finds via the NTP protocol. This may or may
not be a good idea to do. Most offsets > CLOCK_WAYTOOBIG stem from
misconfigured time zone information (leading to a wrong utc time
in the kernel although date seems to show the correct time) and
thus should be corrected before xntp is brought into operation.
If you can trust your synchronisation network and the system configuration
the BIGTIMESTEP option can be used to force xntp to set the time to
network time even when the offsets exceeds CLOCK_WAYTOOBIG.

Frank Kardel ([e-mail])
============================================================================
From: [e-mail] (Ken Stone)
Subject: Re: when is drift value used
Date: 14 Apr 94 23:03:46 GMT
Organization: Hewlett Packard, San Diego Division

>    (1)I'd like to know how and when adjtimed uses "skew" and "drift",
>            which are first and second derivative of offset with time
>            respectively. This drift value is updated every polling?

It doesn't ... all adjtimed does is talk to code in xntpd and emulate the
BSD adjtime(2) system call.

>    (2)The other is about "tick" and "tickadj". I don't understand
>           what these variables(tick and tickadj) originally mean.
>       I mean how these variables are estimated and how will be used.
>       And are these variables only for adjtime()? Not used by "adjtimed"?

tick and tickadj are meaningless (more or less on HP-UX right now.

>        (3)It is said drift balue is specific to the computer xntp runs
>       on(parameter of the computers oscillator).
>       Is there any relation between drift value and these
>       variables(tick and tickadj)?

Not on HP-UX ... at least yet anyway :-)

HP-UX 9.03 for the s300's is shipping now and while it does not have xntpd
shipped with it (and probably never will ?) ... it does have the adjtime(2)
system call !!  Look for NTP support and adjtime(2) on s700/s800 at 10.0.

  -- Ken

============================================================================
From: [e-mail] (Marc Brett)
Subject: Re: HELP WITH CONFIG (Your opinions)
Date: 14 Apr 94 11:09:24 GMT
Organization: Western Geophysical, Div. of Western Atlas Int'l, Houston, TX

Dave Zarnoch ([e-mail]) wrote:

: A.  Is my definition of a "peer" correct for the slaves?

Looks OK to me.

: B.  In my definition for the clients, will they always
:     try to sync with the first server line or will they
:     take an average of the two servers and sync to this?
:     (I really don't want to overload one slave if they
:     will only read the first line only)

Each machine looks at all of the servers and peers in its ntp.conf file
and syncs to the "best" one.  As the clocks stabilize, the total
network load decreases, but all the servers and peers are sampled
periodically (about every 1-17 minutes).

: C. If my timeserver goes down or reboots, will the network
:    try to "keep up" until the timeserver comes back up?

As you have set it up, if the timeserver goes down, then all the slaves
and clients will be running free on their own clocks.  Not good.  To
keep them all in sync, the slaves should have a "server 127.127.1.x"
line, where x is greater than the timeserver's level.  To avoid
contention, the values of x should be different on the two peered
slaves, say 127.127.1.5 on slv07_A and 127.127.1.6 on slv07_B,
127.127.1.5 on slv09_A and 127.127.1.6 on slv09_B (assuming that the A
slaves have the better clocks).  If both A and B slaves are at the same
stratum, then the two slaves' clocks will drift apart and the clients
will "clock hop" between the two.

: D. Are these stratum levels correct?

Free-running time servers probably should be at stratum 10.  If the
clients are nested deeply, then this could be raised so that no
client tries to exceed stratum 16.

: E. Is it necessary to add "ntpdate <internet address>" to
:    my rc.local file also?

No, but it is a very good idea.  Why boot a machine with an inaccurate
clock?  All of our Suns have this in rc.local before the calls to
tickadj and xntpd.

if [ -f /usr/local/bin/ntpdate ]; then
    /usr/local/bin/ntpdate -b <NTP_servers ...> <NTP_slaves ...>
fi

--
Marc Brett              [e-mail]
Western Geophysical     Tel: [phone]

============================================================================
From: [e-mail] (Ken Stone)
Subject: Re: xntpd on HP
Date: 14 Apr 94 23:06:41 GMT
Organization: Hewlett Packard, San Diego Division

>I have gotten xntpd version 3.3q which I plan to implement on an HP700 series
>running HP-UX version 9.  Is it true that this version has eliminated the time-
>warping problem?  Someone please let me know if this is so.  I would also like
>to know where the problem existed and how it was fixed.

I have verified that it is gone at p ... so I would hope that anything after
that is OK also ... the problem was in the handling of adjtime() failing.
Just happens that on most machines, its pretty hard for a simple system
call to fail ... whereas on HP's, adjtime() is anything but a simple system
call :-(

  -- Ken

============================================================================